[Nanog-futures] New Membership-WG Draft
The Membership WG has created a new draft for the community to review and discuss. This draft is not intended to be language for bylaw amendment. Once general consensus is reached on the membership policies work will begin on writing language for bylaw amendment where necessary. The subsections contain notation in parentheses indicating which section of the bylaws are related or already have relevant language. For the purpose of simplifying discussion it should be assumed that section 5 (membership) of the bylaws do not exist. For the Membership WG Kris Foster, chair NewNOG Membership Policy Draft 1.0 Definition of membership 1.1 (Consistent with B3) Members of NewNOG are those individuals who have a demonstrated interest in Internet network operations and have met all necessary requirements set forth in the organization’s bylaws. 2.0 Member rights 2.1 (B8.4) Members have the right to elect individuals to the Board of Directors. 2.1.1 (B8.4.1) Members have the right to nominate individuals as candidates for the filling seats on the Board of Directors. 2.1.2 (B8.4.1) Members have the right to post endorsements of candidates to the NewNOG website, or alongside candidate biographies. 2.2 (B8.4.1 for BoD) Members have the right to nominate for positions on committees set out in the bylaws, or committees that the Board of Directors may create from time-to-time. 2.3 (B14) Members have the right to put forward proposals for ballot propositions that meet the necessary criteria set out in the bylaws. 2.4 (new) Members have the right to participate in governance related functions, forums, and working groups created by the Board of Directors and open to general membership participation. 2.7 (B8.8) Members may remove a sitting Director by a super majority vote of the membership. 3.0 Member privileges 3.1 (B8.9) Only members in good standing may hold a seat on the Board of Directors. 3.1.1 (B8.4) Only members in good standing may be nominated to serve on the Board of Directors. 3.2 (B9) Only members in good standing may hold positions as officers of the corporation. 3.3 (B9) Only members in good standing may hold positions in the corporation’s committees. 3.4 (new) Members are entitled to any benefits approved by the Board of Directors. 3.5 (new) Member benefits shall be published on the NewNOG web site. 3.6 (new) Section 3.3 will come into force for all those appointed after the transition from Merit to NewNOG has completed in its entirety. 4.0 Membership requirements 4.1 (new) Members are required to be active within the Internet network operations community by way of current employment or previous employment if retired, participation in industry forums, academic instruction or scholarship, or volunteer positions. 4.1.1 (new) Members are required to maintain membership dues as set out by the Board of Directors and approved by the membership. 4.1.2 (new) Members must be individuals and may not be organizations of any form. 4.1.3 (new) New memberships will be approved by vote at a meeting of the Board of Directors. 4.4 (new) Directors, officers, and committee members must rectify any lapse in good standing within thirty days. 4.4.1 (new) Committee members who fail to regain good standing within 30 days will become inactive and may be removed from the committee at the discretion of the Board of Directors. 4.4.2 (new) Directors who fail to regain good standing within 30 days may be replaced by an interim director at the discretion of the Board of Directors. 4.5 (new) An individuals membership may be revoked by super majority of Directors. 4.6 (new) Membership is not required to attend the conferences administered by NewNOG. 4.7 (new) The Executive Director must be a member in good standing during the course of their employment with NewNOG. 5.0 Membership dues 5.1 (new) The membership fee structure will be reviewed from time-to-time by the NewNOG Board of Director. The Board of Directors may propose changes to the membership fee structure. Any changes to the fee structure requires a majority vote of current members. 5.2 (new) Dues must be paid prior to receiving any of the rights, privileges, or benefits granted to members. 5.3 (new) Lapses in membership must be paid retroactively up to 12 months to regain good standing. The member’s anniversary date will remain the same. 5.4 (new) Membership which has lapsed up to 12 months is considered inactive. Inactive members are ineligible to any rights, privileges or benefits of membership until the member has returned to good standing. 5.5 (new) Membership which has lapsed in excess of 12 months maybe canceled at the discretion of the Board of Directors. Any future applications for membership by the individual must fulfill the same requirements as a new member. 5.6 (new) Each member will have an anniversary date by which they will need to pay any set membership dues. The anniversary
DDOS attack via as702 87.118.210.122
Hello, list. Please send me off-list abuse contact for as702. -- Serg Shubenkov, MAcomnet, Internet Dept., Head of Inet Department phone: +7 495 7969392/9079, +7 916 5316625, mailto:s...@macomnet.net icq uin: 101964103, Skype: serg.v.shubenkov
Re: DDOS attack via as702 87.118.210.122
Whois is hard, let's go shopping: ja...@anna ~ $ whois as701 # # The following results may also be obtained via: # http://whois.arin.net/rest/asns;q=as701?showDetails=true # ASNumber: 701 - 705 ASName: UUNET ASHandle: AS701 RegDate:1990-08-03 Updated:2008-07-24 Ref:http://whois.arin.net/rest/asn/AS701 OrgName:MCI Communications Services, Inc. d/b/a Verizon Business OrgId: MCICS Address:22001 Loudoun County Pkwy City: Ashburn StateProv: VA PostalCode: 20147 Country:US RegDate:2006-05-30 Updated:2009-12-07 Ref:http://whois.arin.net/rest/org/MCICS OrgTechHandle: JHU140-ARIN OrgTechName: Huffines, Jody OrgTechPhone: +1-703-886-6093 OrgTechEmail: jody.huffi...@verizonbusiness.com OrgTechRef:http://whois.arin.net/rest/poc/JHU140-ARIN OrgAbuseHandle: ABUSE3-ARIN OrgAbuseName: abuse OrgAbusePhone: +1-800-900-0241 OrgAbuseEmail: abuse-m...@verizonbusiness.com OrgAbuseRef:http://whois.arin.net/rest/poc/ABUSE3-ARIN OrgNOCHandle: OA12-ARIN OrgNOCName: UUnet Technologies, Inc., Technologies OrgNOCPhone: +1-800-900-0241 OrgNOCEmail: hel...@verizonbusiness.com OrgNOCRef:http://whois.arin.net/rest/poc/OA12-ARIN OrgTechHandle: SWIPP-ARIN OrgTechName: swipper OrgTechPhone: +1-800-900-0241 OrgTechEmail: swip...@verizonbusiness.com OrgTechRef:http://whois.arin.net/rest/poc/SWIPP-ARIN -Jack Carrozzo On Tue, Oct 26, 2010 at 7:51 AM, Serg Shubenkov s...@macomnet.net wrote: Hello, list. Please send me off-list abuse contact for as702. -- Serg Shubenkov, MAcomnet, Internet Dept., Head of Inet Department phone: +7 495 7969392/9079, +7 916 5316625, mailto:s...@macomnet.net icq uin: 101964103, Skype: serg.v.shubenkov
Re: IPv6 Routing table will be bloated?
Quick comment: IGP bloat != BGP bloat. Your customers cannot announce the space you gave them externally - unless ~/32s, i.e. forced aggregation. Also, your customers shouldn't need to come back for more very often and ideally you have some reservations for them a well :). /TJ PS - apologies for top posting. On Oct 26, 2010 9:59 AM, Jack Bates jba...@brightok.net wrote: So, the best that I can tell (still not through debating with RIR), the IPv6 routing table will see lots of bloat. Here's my reasoning so far: 1) RIR (ARIN in this case, don't know other RIR interpretations) only does initial assignments to barely cover the minimum. If you need more due to routing, you'll need to provide every pop, counts per pop, etc, to show how v6 will require more than just the minimums (full routing plan and customer counts to justify routing plan). HD-Ratio has NO bearing on initial allocation, and while policy dictates that it doesn't matter how an ISP assigns to customer so long as HD-Ratio is met, that is not the case when providing justification for the initial allocation. 2) Subsequent requests only double in size according to policy (so just keep going back over and over since HD is met immediately due to the minimalist initial assignment?) So I conclude that since I get a bare minimum, I can only assign a bare minimum. Since everything is quickly maxed out, I must request more (but only double), which in turn I can assign, but my customer assignments (Telcos/ISPs in this case) will be non-contiguous due to the limited available space I have to hand out. This will lead to IGP bloat, and in cases of multi-homed customers whom I provide address space for, BGP bloat. I'm small, so my bloat factor is small, but I can quickly see this developing exactly as my v4 network did (if it was years ago when I first got my v4 allocation, growing to today, for each allocation I got for v4, I'd expect similar out of v6). Sure, the end user gets loads of space with those nice /48's, but the space within ISPs and their ISP customers is force limited by initial allocations which will create fragmentation of address space. This is brought about due to the dual standard of initial vs subsequent allocations (just enough to cover existing vs HD Ratio). As an example, Using HD-Ratios as an initial assignment metric can warrant a /27, whereas the minimalist approach may only warrant a heavily utilized /30. 3 bits doesn't seem like much, but it's a huge difference in growth room. Bare minimums, as provided by me, only included the /24 IPv4 DHCP pools converted with a raw conversion as /32 IPv4 = /48 IPv6 network Am I missing something, or is this minimalist approach going to cause issues in BGP the same as v4 did? Jack
Re: DDOS attack via as702 87.118.210.122
On Tue, Oct 26, 2010, Cutler James R wrote: Jack, I agree that whois is hard. Please explain how you knew to query AS701 when Serg asked about AS702. Brainfart. I understand why people confuse 701 with 702. $ whois -h whois.ripe.net AS702 % Information related to 'AS702' aut-num:AS702 as-name:AS702 descr: Verizon Business EMEA - Commercial IP service provider in Europe ... Adrian computer:~ me$ whois as702 SNIP No match for AS702. Last update of whois database: Tue, 26 Oct 2010 13:47:47 UTC Regards. Cutler On Oct 26, 2010, at 9:22 AM, Jack Carrozzo wrote: Whois is hard, let's go shopping: ja...@anna ~ $ whois as701 SNIP/ -Jack Carrozzo On Tue, Oct 26, 2010 at 7:51 AM, Serg Shubenkov s...@macomnet.net wrote: Hello, list. Please send me off-list abuse contact for as702. -- Serg Shubenkov, MAcomnet, Internet Dept., Head of Inet Department phone: +7 495 7969392/9079, +7 916 5316625, mailto:s...@macomnet.net icq uin: 101964103, Skype: serg.v.shubenkov James R. Cutler james.cut...@consultant.com -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA -
Re: IPv6 Routing table will be bloated?
On 2010-10-26 15:57, Jack Bates wrote: [..] Am I missing something, or is this minimalist approach going to cause issues in BGP the same as v4 did? You are missing the point of making a proper plan which can justify address space for your business for the next years. If done properly, you have successfully justified it and you will never ever have to go back to any of the five years. Now what will cause routing bloat is folks who keep on doing the same methods of load balancing and chunking out of PA and announcing that in BGP. Oh and then there are of course the various organizations who do not know/understand what RPSL is and who do not understand what filtering and aggregation means... Greets, Jeroen
Re: DDOS attack via as702 87.118.210.122
Whois really isn't that hard Maybe reading: ASNumber: 701 - 705 is though.. t...@shitbox:/var/log$ whois a 702 -h whois.arin.net # # The following results may also be obtained via: # http://whois.arin.net/rest/asns;q=702?showDetails=true # ASNumber: 701 - 705 ASName: UUNET ASHandle: AS701 RegDate:1990-08-03 Updated:2008-07-24 Ref:http://whois.arin.net/rest/asn/AS701 OrgName:MCI Communications Services, Inc. d/b/a Verizon Business OrgId: MCICS Address:22001 Loudoun County Pkwy City: Ashburn StateProv: VA PostalCode: 20147 Country:US RegDate:2006-05-30 Updated:2009-12-07 Ref:http://whois.arin.net/rest/org/MCICS OrgTechHandle: JHU140-ARIN OrgTechName: Huffines, Jody OrgTechPhone: +1-703-886-6093 OrgTechEmail: jody.huffi...@verizonbusiness.com OrgTechRef:http://whois.arin.net/rest/poc/JHU140-ARIN OrgNOCHandle: OA12-ARIN OrgNOCName: UUnet Technologies, Inc., Technologies OrgNOCPhone: +1-800-900-0241 OrgNOCEmail: hel...@verizonbusiness.com OrgNOCRef:http://whois.arin.net/rest/poc/OA12-ARIN OrgTechHandle: SWIPP-ARIN OrgTechName: swipper OrgTechPhone: +1-800-900-0241 OrgTechEmail: swip...@verizonbusiness.com OrgTechRef:http://whois.arin.net/rest/poc/SWIPP-ARIN OrgAbuseHandle: ABUSE3-ARIN OrgAbuseName: abuse OrgAbusePhone: +1-800-900-0241 OrgAbuseEmail: abuse-m...@verizonbusiness.com OrgAbuseRef:http://whois.arin.net/rest/poc/ABUSE3-ARIN # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # On Tue, Oct 26, 2010 at 8:54 AM, Cutler James R james.cut...@consultant.com wrote: Jack, I agree that whois is hard. Please explain how you knew to query AS701 when Serg asked about AS702. computer:~ me$ whois as702 SNIP No match for AS702. Last update of whois database: Tue, 26 Oct 2010 13:47:47 UTC Regards. Cutler
Re: Tools for teaching users online safety
In article 4cc62b29.4040...@blastro.com, Alex Thurlow a...@blastro.com writes I'm trying to find out if there are currently any resources available for teaching people how to be safe online. As in, how to not get a virus, how to pick out phishing emails, how to recognize scams. I'm sure everyone on this list knows these things, but a lot of end users don't. I'm trying to find a way to teach these things to people who aren't too technically savvy. There's quite a bit of information (UK-orientated) at www.e-victims.org, which was intended to cover a wide range of issues but after three years of operation is now focussing on anti-social behaviour rather than scams. But there's a quite a lot of material there about avoiding scams, and advice on what to do if you've been caught. The generic preventative advice is mainly aimed at teenagers. Disclaimer: I'm related to the owner. -- Roland Perry
Re: IPv6 Routing table will be bloated?
On 10/26/2010 9:08 AM, Jeroen Massar wrote: You are missing the point of making a proper plan which can justify address space for your business for the next years. According to ARIN, initial allocations due NOT allot for growth, only for the existing infrastructure. If done properly, you have successfully justified it and you will never ever have to go back to any of the five years. I'd have to lie about existing counts to plan for 5 years. I don't like lying. Now what will cause routing bloat is folks who keep on doing the same methods of load balancing and chunking out of PA and announcing that in BGP. I have customers who use my space and multihome. There is no reason or requirement for them to go to ARIN for this space. They can easily use my own. Ideally they would have (and I would have) large enough space for a single aggregate leaving their network, but with a minimal approach (vs HD-Ratio aligned assignment up front), that won't be possible. Jack
Re: DDOS attack via as702 87.118.210.122
Well, I whois'd 702, got no match, said hm, I see 701 all over the place, lemmy take a look and found: ASNumber: 701 - 705 ASName: UUNET etc. Sorry, it was left as an exercise to the reader - didn't mean to be flippant. -Jack CArrozzo On Tue, Oct 26, 2010 at 10:07 AM, Adrian Chadd adr...@creative.net.auwrote: On Tue, Oct 26, 2010, Cutler James R wrote: Jack, I agree that whois is hard. Please explain how you knew to query AS701 when Serg asked about AS702. Brainfart. I understand why people confuse 701 with 702. $ whois -h whois.ripe.net AS702 % Information related to 'AS702' aut-num:AS702 as-name:AS702 descr: Verizon Business EMEA - Commercial IP service provider in Europe ... Adrian computer:~ me$ whois as702 SNIP No match for AS702. Last update of whois database: Tue, 26 Oct 2010 13:47:47 UTC Regards. Cutler On Oct 26, 2010, at 9:22 AM, Jack Carrozzo wrote: Whois is hard, let's go shopping: ja...@anna ~ $ whois as701 SNIP/ -Jack Carrozzo On Tue, Oct 26, 2010 at 7:51 AM, Serg Shubenkov s...@macomnet.net wrote: Hello, list. Please send me off-list abuse contact for as702. -- Serg Shubenkov, MAcomnet, Internet Dept., Head of Inet Department phone: +7 495 7969392/9079, +7 916 5316625, mailto:s...@macomnet.net icq uin: 101964103, Skype: serg.v.shubenkov James R. Cutler james.cut...@consultant.com -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA -
Re: IPv6 Routing table will be bloated?
On 10/26/2010 9:06 AM, TJ wrote: Quick comment: IGP bloat != BGP bloat. Your customers cannot announce the space you gave them externally - unless ~/32s, i.e. forced aggregation. Still waiting on ARIN to get back to my argument that I am allowed to assign /32s to my subtending ISPs who are of X size or are multihomed. Also, your customers shouldn't need to come back for more very often and ideally you have some reservations for them a well :). If the initial allocation from ARIN is only for current infrastructure and customers (the bare minimum), there is no room for reservation, nor will customers have room to grow in the initial allocation. This is the problem with minimal on initial instead of HD-Ratio (which is what the rest of the policy is based on), but it could lead to fragmented networks. Jack
RE: DDOS attack via as702 87.118.210.122
Must admit I thought what Jack supplied said between AS 701 - 705 which is MCI/Verizon and correct? ASNumber: 701 - 705 ASName: UUNET ASHandle: AS701 RegDate:1990-08-03 Updated:2008-07-24 Ref:http://whois.arin.net/rest/asn/AS701 If you done some manual work like a bit of ripe/cidr-report and used network tools for a whois you would get the answer. Cheers Steven -Original Message- From: Cutler James R [mailto:james.cut...@consultant.com] Sent: 26 October 2010 14:54 To: na...@merit.edu Subject: Re: DDOS attack via as702 87.118.210.122 Jack, I agree that whois is hard. Please explain how you knew to query AS701 when Serg asked about AS702. computer:~ me$ whois as702 SNIP No match for AS702. Last update of whois database: Tue, 26 Oct 2010 13:47:47 UTC Regards. Cutler On Oct 26, 2010, at 9:22 AM, Jack Carrozzo wrote: Whois is hard, let's go shopping: ja...@anna ~ $ whois as701 SNIP/ -Jack Carrozzo On Tue, Oct 26, 2010 at 7:51 AM, Serg Shubenkov s...@macomnet.net wrote: Hello, list. Please send me off-list abuse contact for as702. -- Serg Shubenkov, MAcomnet, Internet Dept., Head of Inet Department phone: +7 495 7969392/9079, +7 916 5316625, mailto:s...@macomnet.net icq uin: 101964103, Skype: serg.v.shubenkov James R. Cutler james.cut...@consultant.com ---BeginMessage--- Whois is hard, let's go shopping: ja...@anna ~ $ whois as701 # # The following results may also be obtained via: # http://whois.arin.net/rest/asns;q=as701?showDetails=true # ASNumber: 701 - 705 ASName: UUNET ASHandle: AS701 RegDate:1990-08-03 Updated:2008-07-24 Ref:http://whois.arin.net/rest/asn/AS701 OrgName:MCI Communications Services, Inc. d/b/a Verizon Business OrgId: MCICS Address:22001 Loudoun County Pkwy City: Ashburn StateProv: VA PostalCode: 20147 Country:US RegDate:2006-05-30 Updated:2009-12-07 Ref:http://whois.arin.net/rest/org/MCICS OrgTechHandle: JHU140-ARIN OrgTechName: Huffines, Jody OrgTechPhone: +1-703-886-6093 OrgTechEmail: jody.huffi...@verizonbusiness.com OrgTechRef:http://whois.arin.net/rest/poc/JHU140-ARIN OrgAbuseHandle: ABUSE3-ARIN OrgAbuseName: abuse OrgAbusePhone: +1-800-900-0241 OrgAbuseEmail: abuse-m...@verizonbusiness.com OrgAbuseRef:http://whois.arin.net/rest/poc/ABUSE3-ARIN OrgNOCHandle: OA12-ARIN OrgNOCName: UUnet Technologies, Inc., Technologies OrgNOCPhone: +1-800-900-0241 OrgNOCEmail: hel...@verizonbusiness.com OrgNOCRef:http://whois.arin.net/rest/poc/OA12-ARIN OrgTechHandle: SWIPP-ARIN OrgTechName: swipper OrgTechPhone: +1-800-900-0241 OrgTechEmail: swip...@verizonbusiness.com OrgTechRef:http://whois.arin.net/rest/poc/SWIPP-ARIN -Jack Carrozzo On Tue, Oct 26, 2010 at 7:51 AM, Serg Shubenkov s...@macomnet.net wrote: Hello, list. Please send me off-list abuse contact for as702. -- Serg Shubenkov, MAcomnet, Internet Dept., Head of Inet Department phone: +7 495 7969392/9079, +7 916 5316625, mailto:s...@macomnet.net icq uin: 101964103, Skype: serg.v.shubenkov ---End Message---
Re: DDOS attack via as702 87.118.210.122
whois on 702(Verizon) http://www.robtex.com/as/as702.html goodluck. On Tue, Oct 26, 2010 at 5:51 AM, Serg Shubenkov s...@macomnet.net wrote: Hello, list. Please send me off-list abuse contact for as702. -- Serg Shubenkov, MAcomnet, Internet Dept., Head of Inet Department phone: +7 495 7969392/9079, +7 916 5316625, mailto:s...@macomnet.net icq uin: 101964103, Skype: serg.v.shubenkov -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Re: Tools for teaching users online safety
On Mon, Oct 25, 2010 at 19:13, Alex Thurlow a...@blastro.com wrote: I'm trying to find out if there are currently any resources available for teaching people how to be safe online. As in, how to not get a virus, how to pick out phishing emails, how to recognize scams. I'm sure everyone on this list knows these things, but a lot of end users don't. I'm trying to find a way to teach these things to people who aren't too technically savvy. It seems to me that the fewer end users that have issues, the easier our lives will be. So what I'm trying to figure out is, is there a good site or set of sites for this stuff, or is there anyone out there interested in helping to build a unified list of instructions, videos, etc. for all this? The Colorado Chapter of the Internet Society (CO ISOC) is in the process of launching a project to do just that. We are calling it (fairly obviously) the Internet User Best Common Practices. As stated on the project's wiki landing page (http://wiki.coisoc.org/index.php/UserBCP): The idea is to start here on the wiki by gathering and creating a repository of information on how to be a good Netizen. That is, how to be a safe and responsible Internet user. We want to use this information, once gathered and verified, to create simple and accessible resources for the general population. I invite you and everyone who reads this to participate, all input is welcome! Thanks, ~Chris (founding chair, CO ISOC) -- Alex Thurlow Blastro Networks http://www.blastro.com http://www.roxwel.com http://www.yallwire.com -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org
Re: IPv6 Routing table will be bloated?
* Jack Bates: So, the best that I can tell (still not through debating with RIR), the IPv6 routing table will see lots of bloat. Here's my reasoning so far: 1) RIR (ARIN in this case, don't know other RIR interpretations) only does initial assignments to barely cover the minimum. If you need more due to routing, you'll need to provide every pop, counts per pop, etc, to show how v6 will require more than just the minimums (full routing plan and customer counts to justify routing plan). If you get better routing and reachability from not filtering at the /32 boundary, network operators will stop filtering at the /32 boundary. So this issue will likely go away pretty soon because you can use our initial assignment to gain the routing flexibility you need. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Cell sites
I am hoping someone can guide me to a internet resource that provides information on newly contstructed cell sites and what provider they are affiliated with? I did some google fu and found a couple sites like antennasearch,towersource etc still no joy, in all cases this new tower does not exist. thanx in advance, harbor235 ;}
re: Cell sites
Well, I'm not sure if there is a database of who is actually colo'ed on a tower. But as for who a tower is owned by, The FCC database works. They also have a cool google earth file that will show you the location of all of them http://www.fccinfo.com/fccinfo_google_earth.php Nick Olsen Network Operations (855) FLSPEED x106 From: harbor235 harbor...@gmail.com Sent: Tuesday, October 26, 2010 11:47 AM To: NANOG list nanog@nanog.org Subject: Cell sites I am hoping someone can guide me to a internet resource that provides information on newly contstructed cell sites and what provider they are affiliated with? I did some google fu and found a couple sites like antennasearch,towersource etc still no joy, in all cases this new tower does not exist. thanx in advance, harbor235 ;}
RE: IPv6 Routing table will be bloated?
You didn't miss anything, past ARIN practice has been broken, though using sparse allocation it is not quite as bad as you project. In any case, ISP's with more than 10k customers should NEVER get a /32, yet that is what ARIN insisted on giving even the largest providers in the region. Every ISP should go back to ARIN, turn in the lame /32 nonsense they were given (that allocation size is for a startup ISP with 0 customers), follow that with an 'initial allocation' request that is based on your pop structure with a /48 per customer including projected growth. I don't care what you actually allocate to your customers at this point, just get a large enough block to begin with that you could give everyone a /48 the way policy allows. There is absolutely no reason to have to grovel at ARIN's feet every few months as you grow your IPv6 deployment. Get a 'real block' up front. Tony -Original Message- From: Jack Bates [mailto:jba...@brightok.net] Sent: Tuesday, October 26, 2010 6:58 AM To: nanog@nanog.org Subject: IPv6 Routing table will be bloated? So, the best that I can tell (still not through debating with RIR), the IPv6 routing table will see lots of bloat. Here's my reasoning so far: 1) RIR (ARIN in this case, don't know other RIR interpretations) only does initial assignments to barely cover the minimum. If you need more due to routing, you'll need to provide every pop, counts per pop, etc, to show how v6 will require more than just the minimums (full routing plan and customer counts to justify routing plan). HD-Ratio has NO bearing on initial allocation, and while policy dictates that it doesn't matter how an ISP assigns to customer so long as HD-Ratio is met, that is not the case when providing justification for the initial allocation. 2) Subsequent requests only double in size according to policy (so just keep going back over and over since HD is met immediately due to the minimalist initial assignment?) So I conclude that since I get a bare minimum, I can only assign a bare minimum. Since everything is quickly maxed out, I must request more (but only double), which in turn I can assign, but my customer assignments (Telcos/ISPs in this case) will be non-contiguous due to the limited available space I have to hand out. This will lead to IGP bloat, and in cases of multi-homed customers whom I provide address space for, BGP bloat. I'm small, so my bloat factor is small, but I can quickly see this developing exactly as my v4 network did (if it was years ago when I first got my v4 allocation, growing to today, for each allocation I got for v4, I'd expect similar out of v6). Sure, the end user gets loads of space with those nice /48's, but the space within ISPs and their ISP customers is force limited by initial allocations which will create fragmentation of address space. This is brought about due to the dual standard of initial vs subsequent allocations (just enough to cover existing vs HD Ratio). As an example, Using HD-Ratios as an initial assignment metric can warrant a /27, whereas the minimalist approach may only warrant a heavily utilized /30. 3 bits doesn't seem like much, but it's a huge difference in growth room. Bare minimums, as provided by me, only included the /24 IPv4 DHCP pools converted with a raw conversion as /32 IPv4 = /48 IPv6 network Am I missing something, or is this minimalist approach going to cause issues in BGP the same as v4 did? Jack
Re: IPv6 Routing table will be bloated?
Totally agree. In IPv6, polices are in some RIRs and MUST be in all them, balancing conservation and aggregation, but in case of conflict aggregation is the top priority. I can read it at the NRPM: 6.3.8. Conflict of goals The goals described above will often conflict with each other, or with the needs of individual IRs or end users. All IRs evaluating requests for allocations and assignments must make judgments, seeking to balance the needs of the applicant with the needs of the Internet community as a whole. In IPv6 address policy, the goal of aggregation is considered to be the most important. Regards, Jordi From: Tony Hain alh-i...@tndh.net Reply-To: alh-i...@tndh.net Date: Tue, 26 Oct 2010 09:02:00 -0700 To: 'Jack Bates' jba...@brightok.net, nanog@nanog.org Subject: RE: IPv6 Routing table will be bloated? You didn't miss anything, past ARIN practice has been broken, though using sparse allocation it is not quite as bad as you project. In any case, ISP's with more than 10k customers should NEVER get a /32, yet that is what ARIN insisted on giving even the largest providers in the region. Every ISP should go back to ARIN, turn in the lame /32 nonsense they were given (that allocation size is for a startup ISP with 0 customers), follow that with an 'initial allocation' request that is based on your pop structure with a /48 per customer including projected growth. I don't care what you actually allocate to your customers at this point, just get a large enough block to begin with that you could give everyone a /48 the way policy allows. There is absolutely no reason to have to grovel at ARIN's feet every few months as you grow your IPv6 deployment. Get a 'real block' up front. Tony -Original Message- From: Jack Bates [mailto:jba...@brightok.net] Sent: Tuesday, October 26, 2010 6:58 AM To: nanog@nanog.org Subject: IPv6 Routing table will be bloated? So, the best that I can tell (still not through debating with RIR), the IPv6 routing table will see lots of bloat. Here's my reasoning so far: 1) RIR (ARIN in this case, don't know other RIR interpretations) only does initial assignments to barely cover the minimum. If you need more due to routing, you'll need to provide every pop, counts per pop, etc, to show how v6 will require more than just the minimums (full routing plan and customer counts to justify routing plan). HD-Ratio has NO bearing on initial allocation, and while policy dictates that it doesn't matter how an ISP assigns to customer so long as HD-Ratio is met, that is not the case when providing justification for the initial allocation. 2) Subsequent requests only double in size according to policy (so just keep going back over and over since HD is met immediately due to the minimalist initial assignment?) So I conclude that since I get a bare minimum, I can only assign a bare minimum. Since everything is quickly maxed out, I must request more (but only double), which in turn I can assign, but my customer assignments (Telcos/ISPs in this case) will be non-contiguous due to the limited available space I have to hand out. This will lead to IGP bloat, and in cases of multi-homed customers whom I provide address space for, BGP bloat. I'm small, so my bloat factor is small, but I can quickly see this developing exactly as my v4 network did (if it was years ago when I first got my v4 allocation, growing to today, for each allocation I got for v4, I'd expect similar out of v6). Sure, the end user gets loads of space with those nice /48's, but the space within ISPs and their ISP customers is force limited by initial allocations which will create fragmentation of address space. This is brought about due to the dual standard of initial vs subsequent allocations (just enough to cover existing vs HD Ratio). As an example, Using HD-Ratios as an initial assignment metric can warrant a /27, whereas the minimalist approach may only warrant a heavily utilized /30. 3 bits doesn't seem like much, but it's a huge difference in growth room. Bare minimums, as provided by me, only included the /24 IPv4 DHCP pools converted with a raw conversion as /32 IPv4 = /48 IPv6 network Am I missing something, or is this minimalist approach going to cause issues in BGP the same as v4 did? Jack ** The IPv6 Portal: http://www.ipv6tf.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: IPv6 Routing table will be bloated?
On Oct 26, 2010, at 7:06 AM, TJ wrote: Quick comment: IGP bloat != BGP bloat. Your customers cannot announce the space you gave them externally - unless ~/32s, i.e. forced aggregation. He's talking about the bloat that comes from ISPs getting slow-started and then only being able to increase their network in increments of 2x each time, so, effectively ISP gets: 1 x /32 Initial Fills that up, gets 1 x /32 First subsequent Then 1 x /31 then 1 x /30 etc. Probably not quite as bad as IPv4, but, potentially close. Also, your customers shouldn't need to come back for more very often and ideally you have some reservations for them a well :). Consider the scenario where you're dealing with an ISP that provides services to other ISPs as his downstream customers and the above statement doesn't hold true like you think it should. Owen /TJ PS - apologies for top posting. On Oct 26, 2010 9:59 AM, Jack Bates jba...@brightok.net wrote: So, the best that I can tell (still not through debating with RIR), the IPv6 routing table will see lots of bloat. Here's my reasoning so far: 1) RIR (ARIN in this case, don't know other RIR interpretations) only does initial assignments to barely cover the minimum. If you need more due to routing, you'll need to provide every pop, counts per pop, etc, to show how v6 will require more than just the minimums (full routing plan and customer counts to justify routing plan). HD-Ratio has NO bearing on initial allocation, and while policy dictates that it doesn't matter how an ISP assigns to customer so long as HD-Ratio is met, that is not the case when providing justification for the initial allocation. 2) Subsequent requests only double in size according to policy (so just keep going back over and over since HD is met immediately due to the minimalist initial assignment?) So I conclude that since I get a bare minimum, I can only assign a bare minimum. Since everything is quickly maxed out, I must request more (but only double), which in turn I can assign, but my customer assignments (Telcos/ISPs in this case) will be non-contiguous due to the limited available space I have to hand out. This will lead to IGP bloat, and in cases of multi-homed customers whom I provide address space for, BGP bloat. I'm small, so my bloat factor is small, but I can quickly see this developing exactly as my v4 network did (if it was years ago when I first got my v4 allocation, growing to today, for each allocation I got for v4, I'd expect similar out of v6). Sure, the end user gets loads of space with those nice /48's, but the space within ISPs and their ISP customers is force limited by initial allocations which will create fragmentation of address space. This is brought about due to the dual standard of initial vs subsequent allocations (just enough to cover existing vs HD Ratio). As an example, Using HD-Ratios as an initial assignment metric can warrant a /27, whereas the minimalist approach may only warrant a heavily utilized /30. 3 bits doesn't seem like much, but it's a huge difference in growth room. Bare minimums, as provided by me, only included the /24 IPv4 DHCP pools converted with a raw conversion as /32 IPv4 = /48 IPv6 network Am I missing something, or is this minimalist approach going to cause issues in BGP the same as v4 did? Jack
Re: Cell sites
You may find this site helpful: http://www.cellreception.com/towers/ ---rsk
Re: Cell sites
I am hoping someone can guide me to a internet resource that provides information on newly contstructed cell sites and what provider they are affiliated with? http://wireless2.fcc.gov/UlsApp/UlsSearch/searchGeographic.jsp You can do a coordinate search among other things. Note .. this will tell you who has radios on the tower. If it's an empty steel mast, it doesn't need to be in the FCC license database. Depending on how tall it as and/or proximity to airports, it might also be here (FAA required registrations) even if it's empty : http://wireless2.fcc.gov/UlsApp/AsrSearch/towairSearch.jsp Regards, Michael Holstein Cleveland State University
Re: IPv6 Routing table will be bloated?
dusty old routers with ram problems... solution there: re-think the way you do your routing and compare the price of ram versus cpu cycles. (as well as having custom hardware developed to do it on, intel simply does not offer enough address bus lines to maintain bigass tables and address them linearily so you can keep entries for each ip or mac address out there and counters with them to automatically migitate ddos attacks and give every communications partner their own fair share on the outgoing interface's capacity). (and no, we're not talking linux/bsd here... just dedicated routing firmware on let's say ibm's power-6/power-7 platform) instead of buying the same old shit from juniper/cisco/foundry again which doesn't even have enough ram to announce /30's ipv4 (if everyone would do so ;), let alone properly prevent ddos attacks from even being possible -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. Co. KG = Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration:HRA 42834 B BERLINPhone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE:CBSK1-RIPEe-Mail: s...@cb3rob.net = penpen C3P0, der elektrische Westerwelle = Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Tue, 26 Oct 2010, Owen DeLong wrote: On Oct 26, 2010, at 7:06 AM, TJ wrote: Quick comment: IGP bloat != BGP bloat. Your customers cannot announce the space you gave them externally - unless ~/32s, i.e. forced aggregation. He's talking about the bloat that comes from ISPs getting slow-started and then only being able to increase their network in increments of 2x each time, so, effectively ISP gets: 1 x /32 Initial Fills that up, gets 1 x /32 First subsequent Then 1 x /31 then 1 x /30 etc. Probably not quite as bad as IPv4, but, potentially close. Also, your customers shouldn't need to come back for more very often and ideally you have some reservations for them a well :). Consider the scenario where you're dealing with an ISP that provides services to other ISPs as his downstream customers and the above statement doesn't hold true like you think it should. Owen /TJ PS - apologies for top posting. On Oct 26, 2010 9:59 AM, Jack Bates jba...@brightok.net wrote: So, the best that I can tell (still not through debating with RIR), the IPv6 routing table will see lots of bloat. Here's my reasoning so far: 1) RIR (ARIN in this case, don't know other RIR interpretations) only does initial assignments to barely cover the minimum. If you need more due to routing, you'll need to provide every pop, counts per pop, etc, to show how v6 will require more than just the minimums (full routing plan and customer counts to justify routing plan). HD-Ratio has NO bearing on initial allocation, and while policy dictates that it doesn't matter how an ISP assigns to customer so long as HD-Ratio is met, that is not the case when providing justification for the initial allocation. 2) Subsequent requests only double in size according to policy (so just keep going back over and over since HD is met immediately due to the minimalist initial assignment?) So I conclude that since I get a bare minimum, I can only assign a bare minimum. Since everything is quickly maxed out, I must request more (but only double), which in turn I can assign, but my customer assignments (Telcos/ISPs in this case) will be non-contiguous due to the limited available space I have to hand out. This will lead to IGP bloat, and in cases of multi-homed customers whom I provide address space for, BGP bloat. I'm small, so my bloat factor is small, but I can quickly see this developing exactly as my v4 network did (if it was years ago when I first got my v4 allocation, growing to today, for each allocation I got for v4, I'd expect similar out of v6). Sure, the end user gets loads of space with those nice /48's, but the space within ISPs and their ISP customers is force limited by initial allocations which will create fragmentation of address space. This is brought about due to the dual standard of initial vs subsequent allocations (just enough to cover existing vs HD Ratio). As an example, Using HD-Ratios as an initial assignment metric can warrant a /27, whereas the minimalist approach may only warrant a heavily utilized
Re: IPv6 Routing table will be bloated?
On 26/10/2010 17:23, Owen DeLong wrote: He's talking about the bloat that comes from ISPs getting slow-started and then only being able to increase their network in increments of 2x each time, so, effectively ISP gets: [...] Probably not quite as bad as IPv4, but, potentially close. In theory, yes, it's bad. In practice, the RIRs are implementing sparse allocation which makes it possible to aggregate subsequent allocations. I.e. not as bad as it may seem. ARIN, RIPE and AfriNIC, for example, allocate on /29 boundaries. So if you get an initial allocation of /32, then find you need more, your subsequent allocations will be taken from the same /29, allowing aggregation up to /29. APNIC seem to be delegating on /22 boundaries, and LACNIC on /28. Nick
Re: IPv6 Routing table will be bloated?
On 10/26/2010 12:04 PM, Nick Hilliard wrote: In practice, the RIRs are implementing sparse allocation which makes it possible to aggregate subsequent allocations. I.e. not as bad as it may seem. Except, if you are given bare minimums, and you are assigning out to subtending ISPs bare minimums, those subtending ISPs will end up with multiple networks. Some of them are BGP speakers. I can't use sparse allocation because I was given minimum space and not the HD-Ratio threshold space. ARIN, RIPE and AfriNIC, for example, allocate on /29 boundaries. So if you get an initial allocation of /32, then find you need more, your subsequent allocations will be taken from the same /29, allowing aggregation up to /29. My minimum /30 allocation per ARIN met a /27 in HD-Ratio thresholds. To not be given the threshold space means no reservations for subtending ISPs, no room for subtending ISPs to grow, and multiple assignments. If ARIN only does /29 boundaries, I'll also be getting multiple /29's, and not just working within a /27 per the HD-Ratio guidelines. It's the mixed viewpoint that is the problem. HD-Ratio is useless as a justification and as a metric which promotes route conservation/aggregation if it is not used for initial allocations. Initial allocations (including those handed out to subtending ISPs) should all be as large as the immediate use HD Ratio permits. ie, If you are immediately assigning X /56 blocks, your assignment should have a length one less than the highest threshold you crossed. To assign any less is to constrain the assignments, not allow for growth, and to increase routing table size. It also circumvents and completely destroys the concept of HD Ratio (as the initial assignments all are well in excess of the thresholds for requesting much larger blocks). Jack
Re: IPv6 Routing table will be bloated?
On 26/10/2010 18:19, Jack Bates wrote: My minimum /30 allocation per ARIN met a /27 in HD-Ratio thresholds. To not be given the threshold space means no reservations for subtending ISPs, no room for subtending ISPs to grow, and multiple assignments. If ARIN only does /29 boundaries, I'll also be getting multiple /29's, and not just working within a /27 per the HD-Ratio guidelines. If the policy is broken, then submit a policy proposal to fix it. Nick
Re: IPv6 Routing table will be bloated?
I think ARIN is now doing sparse allocations on /28 boundaries. My personal opinion is that it should be even more sparse, and that allocations should be done on nibble boundaries. Any reasonably-sized ISP should get at least a /28. I deal with many small-ish ISPs, and most are 5,000-10,000 users. Those are probably served by a /32 for quite some time. When you get into the ones that are 20,000-50,000, it gets tricker to deal with. Those should get a /28. The mega-ISPs should get a /24, or even a /20. Another problem is that the allocations from IANA to the RIRs are too small to begin with. If there are 5 RIRs, why does there have to be so much fragmentation? It is too late for that, though. Anyway, I think there are some proposals floating around (Owen? ;-) ) That would make the /32,/28,/24 (nibble boundary) idea into policy. We'll have to wait and see what happens. -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 - Original Message - On 26/10/2010 17:23, Owen DeLong wrote: He's talking about the bloat that comes from ISPs getting slow-started and then only being able to increase their network in increments of 2x each time, so, effectively ISP gets: [...] Probably not quite as bad as IPv4, but, potentially close. In theory, yes, it's bad. In practice, the RIRs are implementing sparse allocation which makes it possible to aggregate subsequent allocations. I.e. not as bad as it may seem. ARIN, RIPE and AfriNIC, for example, allocate on /29 boundaries. So if you get an initial allocation of /32, then find you need more, your subsequent allocations will be taken from the same /29, allowing aggregation up to /29. APNIC seem to be delegating on /22 boundaries, and LACNIC on /28. Nick
Re: DDOS attack via as702 87.118.210.122
On Tue, Oct 26, 2010 at 9:12 AM, Jack Carrozzo j...@crepinc.com wrote: Well, I whois'd 702, got no match, said hm, I see 701 all over the place, lemmy take a look and found: There is a match... I think WHOIS as702 is erroneous WHOIS query syntax, typing asX not being the way to search for an AS number. See the full WHOIS help for the details about how to use all the flags, Try searching for the number and use an 'a' search type instead of searching for 'as702'. Try telnet whois.arin.net nicname Escape character is '^]'. a 702 a 702 Gives a match... as702 does not. as701 does; probably because there is the ASHANDLE field or something else in the record that matches that query other than the AS number itself. ASNumber: 701 - 705 ASName: UUNET -- -JH
Re: IPv6 Routing table will be bloated?
- Original Message - On 10/26/2010 12:04 PM, Nick Hilliard wrote: In practice, the RIRs are implementing sparse allocation which makes it possible to aggregate subsequent allocations. I.e. not as bad as it may seem. Except, if you are given bare minimums, and you are assigning out to subtending ISPs bare minimums, those subtending ISPs will end up with multiple networks. Some of them are BGP speakers. I can't use sparse allocation because I was given minimum space and not the HD-Ratio threshold space. Wait... If you are issuing space to ISPs that are multihomed, they should be getting their own addresses. Even if they aren't multihomed, they should probably be getting their own addresses. Why would you be supplying them with address space if they are an ISP? -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1
Re: NTP Server
On Mon, 25 Oct 2010, Robert E. Seastrom wrote: The folks at NRC in Canada will do cryptographically authenticated NTP with you for an annual fee. I have no idea if there is something Robert, Thanks for the shout. NRC does do this, more info here: http://www.nrc-cnrc.gc.ca/eng/services/inms/time-services/network-time.html You can use the services as well for non-auth. I should also point out to folks on this list that the NRC NTP servers have renumbered, but I still see quite a bit of traffic from what appears to be ISP infrastructure looking for the old addresses. wfms
Re: IPv6 Routing table will be bloated?
On Tue, Oct 26, 2010 at 21:19, Sven Olaf Kamphuis s...@cb3rob.net wrote: On Tue, 26 Oct 2010, Randy Carpenter wrote: - Original Message - On 10/26/2010 12:04 PM, Nick Hilliard wrote: In practice, the RIRs are implementing sparse allocation which makes it possible to aggregate subsequent allocations. I.e. not as bad as it may seem. Except, if you are given bare minimums, and you are assigning out to subtending ISPs bare minimums, those subtending ISPs will end up with multiple networks. Some of them are BGP speakers. I can't use sparse allocation because I was given minimum space and not the HD-Ratio threshold space. Wait... If you are issuing space to ISPs that are multihomed, they should be getting their own addresses. Even if they aren't multihomed, they should probably be getting their own addresses. Why would you be supplying them with address space if they are an ISP? -Randy to my knowledge, RIPE still does not issue ipv6 PI space. so giving them their own space, is problematic to say the least. I got a /48 PI from RIPE a few months back. Maybe your knowledge needs to be a little bit refreshed regarding RIPE allocation policies :)
Re: IPv6 Routing table will be bloated?
On Tue, Oct 26, 2010 at 21:19, Sven Olaf Kamphuis s...@cb3rob.net wrote: On Tue, 26 Oct 2010, Randy Carpenter wrote: - Original Message - On 10/26/2010 12:04 PM, Nick Hilliard wrote: In practice, the RIRs are implementing sparse allocation which makes it possible to aggregate subsequent allocations. I.e. not as bad as it may seem. Except, if you are given bare minimums, and you are assigning out to subtending ISPs bare minimums, those subtending ISPs will end up with multiple networks. Some of them are BGP speakers. I can't use sparse allocation because I was given minimum space and not the HD-Ratio threshold space. Wait... If you are issuing space to ISPs that are multihomed, they should be getting their own addresses. Even if they aren't multihomed, they should probably be getting their own addresses. Why would you be supplying them with address space if they are an ISP? -Randy to my knowledge, RIPE still does not issue ipv6 PI space. so giving them their own space, is problematic to say the least. I got a /48 PI from RIPE a few months back. Maybe your knowledge needs to be a little bit refreshed regarding RIPE allocation policies :) Magically, indeed, an ipv6 pi request form showed up in the lirportal. amazing!
Re: IPv6 Routing table will be bloated?
On Tue, Oct 26, 2010 at 2:19 PM, Sven Olaf Kamphuis s...@cb3rob.net wrote: On Tue, 26 Oct 2010, Randy Carpenter wrote: - Original Message - On 10/26/2010 12:04 PM, Nick Hilliard wrote: In practice, the RIRs are implementing sparse allocation which makes it possible to aggregate subsequent allocations. I.e. not as bad as it may seem. Except, if you are given bare minimums, and you are assigning out to subtending ISPs bare minimums, those subtending ISPs will end up with multiple networks. Some of them are BGP speakers. I can't use sparse allocation because I was given minimum space and not the HD-Ratio threshold space. Wait... If you are issuing space to ISPs that are multihomed, they should be getting their own addresses. Even if they aren't multihomed, they should probably be getting their own addresses. Why would you be supplying them with address space if they are an ISP? -Randy to my knowledge, RIPE still does not issue ipv6 PI space. so giving them their own space, is problematic to say the least. ISP's get an LIR assignemnt from RIPE, no? http://www.ripe.net/ripe/docs/ripe-481.html#lir Customers could get an end-user assignment (PA space normally or PI) http://www.ripe.net/ripe/docs/ripe-481.html#_8._IPv6_Provider (ripe PI assignment policies) -chris -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. Co. KG = Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: s...@cb3rob.net = penpen C3P0, der elektrische Westerwelle = Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited.
Re: IPv6 Routing table will be bloated?
On Oct 26, 2010, at 11:19 AM, Sven Olaf Kamphuis wrote: On Tue, 26 Oct 2010, Randy Carpenter wrote: - Original Message - On 10/26/2010 12:04 PM, Nick Hilliard wrote: In practice, the RIRs are implementing sparse allocation which makes it possible to aggregate subsequent allocations. I.e. not as bad as it may seem. Except, if you are given bare minimums, and you are assigning out to subtending ISPs bare minimums, those subtending ISPs will end up with multiple networks. Some of them are BGP speakers. I can't use sparse allocation because I was given minimum space and not the HD-Ratio threshold space. Wait... If you are issuing space to ISPs that are multihomed, they should be getting their own addresses. Even if they aren't multihomed, they should probably be getting their own addresses. Why would you be supplying them with address space if they are an ISP? -Randy to my knowledge, RIPE still does not issue ipv6 PI space. so giving them their own space, is problematic to say the least. RIPE issues PI space in a couple of different forms... 1. Sponsoring LIR can pay 50 Euros/year and subsequently bill the recipient whatever they choose for the PI space. 2. RIPE has always issued PI space to LIRs (ISPs are by definition LIRs). 3. This is NANOG. NA != EU. Owen
RE: IPv6 Routing table will be bloated?
-Original Message- From: Jack Bates [mailto:jba...@brightok.net] Sent: Tuesday, October 26, 2010 11:23 AM To: Randy Carpenter Cc: nanog@nanog.org Subject: Re: IPv6 Routing table will be bloated? On 10/26/2010 1:01 PM, Randy Carpenter wrote: Wait... If you are issuing space to ISPs that are multihomed, they should be getting their own addresses. Even if they aren't multihomed, they should probably be getting their own addresses. Why would you be supplying them with address space if they are an ISP? Because they are my customer. They don't know much about RIRs, paying membership fees, etc. They just know they want address space, and I provide that. If they are ISPs and don't know much about RIRs, can you please name them and provide their ASNs ... oh, wait ... they won't have an ASN if they don't know about RIRs and fees and such. Something isn't passing the smell test here.
Re: IPv6 Routing table will be bloated?
On Tue, Oct 26, 2010 at 14:20, George Bonser gbon...@seven.com wrote: -Original Message- From: Jack Bates [mailto:jba...@brightok.net] On 10/26/2010 1:01 PM, Randy Carpenter wrote: Wait... If you are issuing space to ISPs that are multihomed, they should be getting their own addresses. Even if they aren't multihomed, they should probably be getting their own addresses. Why would you be supplying them with address space if they are an ISP? Because they are my customer. They don't know much about RIRs, paying membership fees, etc. They just know they want address space, and I provide that. If they are ISPs and don't know much about RIRs, can you please name them and provide their ASNs ... oh, wait ... they won't have an ASN if they don't know about RIRs and fees and such. Something isn't passing the smell test here. This is actually not that uncommon. You see it a lot in the smaller level. I had several such clients at my last job. They want to be multi-homed for redundancy, but either don't have enough space, or don't want to pay full time people, so they use a small to midsize ISP and their space and assistance to set up. -Blake
Re: IPv6 Routing table will be bloated?
2. RIPE has always issued PI space to LIRs (ISPs are by definition LIRs). ISPs are not per-se LIRs. LIRs register IP space on behalf of customers customers that do not make delegations themselves (i'm quite sure you don't put each and every one of your access customers into whois, for one thing because that would violate privacy laws :P do not need to be a LIR, and can just do so on PI space. Shared hosting ISPs also do not make subdelegations and generally don't even uses the ips on a one-specific-customer-per-ip basis. So no, ISP's do not have to be a LIR, and LIRs do not have to be an ISP. (in fact, we are considering moving our LIR activities to a completely seperate legal entity from our internet activities). as a LIR is just a buro that issues IP space and does not nessesarily own or operate a network. -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. Co. KG = Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration:HRA 42834 B BERLINPhone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE:CBSK1-RIPEe-Mail: s...@cb3rob.net = penpen C3P0, der elektrische Westerwelle = Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Tue, 26 Oct 2010, Owen DeLong wrote: On Oct 26, 2010, at 11:19 AM, Sven Olaf Kamphuis wrote: On Tue, 26 Oct 2010, Randy Carpenter wrote: - Original Message - On 10/26/2010 12:04 PM, Nick Hilliard wrote: In practice, the RIRs are implementing sparse allocation which makes it possible to aggregate subsequent allocations. I.e. not as bad as it may seem. Except, if you are given bare minimums, and you are assigning out to subtending ISPs bare minimums, those subtending ISPs will end up with multiple networks. Some of them are BGP speakers. I can't use sparse allocation because I was given minimum space and not the HD-Ratio threshold space. Wait... If you are issuing space to ISPs that are multihomed, they should be getting their own addresses. Even if they aren't multihomed, they should probably be getting their own addresses. Why would you be supplying them with address space if they are an ISP? -Randy to my knowledge, RIPE still does not issue ipv6 PI space. so giving them their own space, is problematic to say the least. RIPE issues PI space in a couple of different forms... 1. Sponsoring LIR can pay 50 Euros/year and subsequently bill the recipient whatever they choose for the PI space. 2. RIPE has always issued PI space to LIRs (ISPs are by definition LIRs). 3. This is NANOG. NA != EU. Owen
Re: IPv6 Routing table will be bloated?
HAHA that would totally make the MAFIAA's day... entering all your dialup and adsl customers into whois as they would be end users :P quite sure the EU would not agree on that definition of what constitutes an end-user, and therefore, its quite possible to provide access services on PI space (as you don't make sub delegations anyway) On Tue, 26 Oct 2010, Sven Olaf Kamphuis wrote: 2. RIPE has always issued PI space to LIRs (ISPs are by definition LIRs). ISPs are not per-se LIRs. LIRs register IP space on behalf of customers customers that do not make delegations themselves (i'm quite sure you don't put each and every one of your access customers into whois, for one thing because that would violate privacy laws :P do not need to be a LIR, and can just do so on PI space. Shared hosting ISPs also do not make subdelegations and generally don't even uses the ips on a one-specific-customer-per-ip basis. So no, ISP's do not have to be a LIR, and LIRs do not have to be an ISP. (in fact, we are considering moving our LIR activities to a completely seperate legal entity from our internet activities). as a LIR is just a buro that issues IP space and does not nessesarily own or operate a network. -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. Co. KG = Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration:HRA 42834 B BERLINPhone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE:CBSK1-RIPEe-Mail: s...@cb3rob.net = penpen C3P0, der elektrische Westerwelle = Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Tue, 26 Oct 2010, Owen DeLong wrote: On Oct 26, 2010, at 11:19 AM, Sven Olaf Kamphuis wrote: On Tue, 26 Oct 2010, Randy Carpenter wrote: - Original Message - On 10/26/2010 12:04 PM, Nick Hilliard wrote: In practice, the RIRs are implementing sparse allocation which makes it possible to aggregate subsequent allocations. I.e. not as bad as it may seem. Except, if you are given bare minimums, and you are assigning out to subtending ISPs bare minimums, those subtending ISPs will end up with multiple networks. Some of them are BGP speakers. I can't use sparse allocation because I was given minimum space and not the HD-Ratio threshold space. Wait... If you are issuing space to ISPs that are multihomed, they should be getting their own addresses. Even if they aren't multihomed, they should probably be getting their own addresses. Why would you be supplying them with address space if they are an ISP? -Randy to my knowledge, RIPE still does not issue ipv6 PI space. so giving them their own space, is problematic to say the least. RIPE issues PI space in a couple of different forms... 1. Sponsoring LIR can pay 50 Euros/year and subsequently bill the recipient whatever they choose for the PI space. 2. RIPE has always issued PI space to LIRs (ISPs are by definition LIRs). 3. This is NANOG. NA != EU. Owen
RE: IPv6 Routing table will be bloated?
Shared hosting ISPs also do not make subdelegations and generally don't even uses the ips on a one-specific-customer-per-ip basis. But how do they multihome without an ASN? If they have an ASN, how did they get it without going to an RIR and paying a fee?
RE: IPv6 Routing table will be bloated?
On Tue, 26 Oct 2010, George Bonser wrote: To: Sven Olaf Kamphuis s...@cb3rob.net Shared hosting ISPs also do not make subdelegations and generally don't even uses the ips on a one-specific-customer-per-ip basis. But how do they multihome without an ASN? If they have an ASN, how did they get it without going to an RIR and paying a fee? Legacy ASN assignment? Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: t...@lava.net
Re: IPv6 Routing table will be bloated?
On Tue, Oct 26, 2010 at 14:45, George Bonser gbon...@seven.com wrote: Shared hosting ISPs also do not make subdelegations and generally don't even uses the ips on a one-specific-customer-per-ip basis. But how do they multihome without an ASN? If they have an ASN, how did they get it without going to an RIR and paying a fee? Its not that hard to get an ASN, and all the work can be done by said ISP on behaf of the client, especially many years ago. The extent of one client's knowledge was to turn off a provider router if they were having problems, anything else was handled by us, even with the other ISPs of the client. -Blake
RE: IPv6 Routing table will be bloated?
eh don't know about you americans but here in europe you just go to a LIR and ask them to register an AS for you. there are ofcourse maintenance fees nowadays. On Tue, 26 Oct 2010, George Bonser wrote: Shared hosting ISPs also do not make subdelegations and generally don't even uses the ips on a one-specific-customer-per-ip basis. But how do they multihome without an ASN? If they have an ASN, how did they get it without going to an RIR and paying a fee?
Re: IPv6 Routing table will be bloated?
We also have various customers that only obtain LIR registration services and have no network links whatsoever with us (so just PI and/or AS registration, no transit or whatever) which -is- what a LIR does.. operating a network has nothing to do with being a LIR per-se. On Tue, 26 Oct 2010, Blake Dunlap wrote: On Tue, Oct 26, 2010 at 14:45, George Bonser gbon...@seven.com wrote: Shared hosting ISPs also do not make subdelegations and generally don't even uses the ips on a one-specific-customer-per-ip basis. But how do they multihome without an ASN? If they have an ASN, how did they get it without going to an RIR and paying a fee? Its not that hard to get an ASN, and all the work can be done by said ISP on behaf of the client, especially many years ago. The extent of one client's knowledge was to turn off a provider router if they were having problems, anything else was handled by us, even with the other ISPs of the client. -Blake
Re: IPv6 Routing table will be bloated?
On Oct 26, 2010, at 2:45 PM, George Bonser wrote: But how do they multihome without an ASN? If they have an ASN, how did they get it without going to an RIR and paying a fee? I beleive Jack said that they have redundant connections to his network. I took that to mean that they did not multihome to different AS. Such arrangements are not uncommon. Sprint seems to have done very well selling this sort of near-turnkey service to rural DSL carriers, tiny single town MSOs and the like. --Chris
Re: IPv6 Routing table will be bloated?
On 10/26/2010 2:26 PM, Blake Dunlap wrote: This is actually not that uncommon. You see it a lot in the smaller level. I had several such clients at my last job. They want to be multi-homed for redundancy, but either don't have enough space, or don't want to pay full time people, so they use a small to midsize ISP and their space and assistance to set up. Some aren't multihomed, but they use larger than /20 of v4 space and so still qualify. Others are smaller and multihomed and with my permission (since I configured the BGP for them), use my ASN and routing tricks. Since they have grown this way, they often have no desires to renumber, and most have no desire to even bother with an ASN. However, given the price of an ASN vs price of an ASN and ISP v6 /32; I know exactly which they'll choose. They'll let me pay the higher membership fees, and just get space from me. Jack
Re: IPv6 Routing table will be bloated?
what's the problem anyway with 32bit ASN's there should be enough AS namespace to give everyone that wants to multihome their ipv6/ipv4 PI their own AS number... should pretty much be the de-facto standard (unless ofcourse you want to tie your customers to your internet-provider-activities by making it hard to leave) maybe we should have made AS numbers 64 bit as well... so there would be one for every /64 end user as for the rest of it: get routers with more ram (i don't want to hear any my border routers have less than 8GB of ram) arguments, that stuff is -old-, it's got gray hair and a beard and belongs in a museum, not on the internet) The internet will grow, you can't expect it to grow less fast or to aggregate routes just because your technically outdated stuff doesn't have enough ram to handle the growing route table size. (preferably offset-based rather than with a sort/lookup mechanism) if a customer has a /64 and wants to announce that /64 himself, i see no reason not to give it to them, especially not if hte only reason would be that some people run still routers that have less ram than my eeepc. (and some suppliers still think that's OK to sell) On Tue, 26 Oct 2010, Chris Boyd wrote: On Oct 26, 2010, at 2:45 PM, George Bonser wrote: But how do they multihome without an ASN? If they have an ASN, how did they get it without going to an RIR and paying a fee? I beleive Jack said that they have redundant connections to his network. I took that to mean that they did not multihome to different AS. Such arrangements are not uncommon. Sprint seems to have done very well selling this sort of near-turnkey service to rural DSL carriers, tiny single town MSOs and the like. --Chris
Re: IPv6 Routing table will be bloated?
Why would the assumption be the ISP = knowledgeable or even caring about RIRs, etc.? When I started my ISP 6 years ago I knew someone issued IP addresses to my upstream provider, but I really didn't care who that was. The upstream took care of everything related to getting and assigning addresses as far as I was concerned. Even when I changed upstream providers they took care of the addresses. It was at that time I realized I need to learn more about the whole IP address assignment process so I wouldn't have to renumber next time I changed providers. I dug far enough to find that my ISP was not big enough to get an assignment and the required fee was more than the cost to renumber, so I didn't look any farther. So, as a log of start-ups and small businesses do, I learned enough to make what I needed work, but not everything that may have been beneficial. On 10/26/2010 3:20 PM, George Bonser wrote: -Original Message- From: Jack Bates [mailto:jba...@brightok.net] Sent: Tuesday, October 26, 2010 11:23 AM To: Randy Carpenter Cc: nanog@nanog.org Subject: Re: IPv6 Routing table will be bloated? On 10/26/2010 1:01 PM, Randy Carpenter wrote: Wait... If you are issuing space to ISPs that are multihomed, they should be getting their own addresses. Even if they aren't multihomed, they should probably be getting their own addresses. Why would you be supplying them with address space if they are an ISP? Because they are my customer. They don't know much about RIRs, paying membership fees, etc. They just know they want address space, and I provide that. If they are ISPs and don't know much about RIRs, can you please name them and provide their ASNs ... oh, wait ... they won't have an ASN if they don't know about RIRs and fees and such. Something isn't passing the smell test here. -- Scott Reed Owner NewWays Networking, LLC Wireless Networking Network Design, Installation and Administration Mikrotik Advanced Certified www.nwwnet.net (765) 855-1060
Re: IPv6 Routing table will be bloated?
On Tue, Oct 26, 2010 at 12:45:45PM -0700, George Bonser wrote: But how do they multihome without an ASN? Well, get space from one of your providers, and an LOA to get the other to announce the deaggregate for you. Or they've got legacy space, and never had an AS; just get their providers to announce it for them. If they have an ASN, how did they get it without going to an RIR and paying a fee? Legacy assignment...acquisition... And maybe they did, but just because they pay their RIR for an ASN doesn't mean they want to step up into the fees and documentation headaches of getting their own space. () Some are even singlehomed with an ASN. (I can think of at least two regional providers that had an ASN while being singlehomed because they had downstream BGP speaking customers.) Just because you don't do it, doesn't mean someone else doesn't. It's a big world. --msa
RE: IPv6 Routing table will be bloated?
From: Chris Boyd Sent: Tuesday, October 26, 2010 1:08 PM To: NANOG Subject: Re: IPv6 Routing table will be bloated? I beleive Jack said that they have redundant connections to his network. I took that to mean that they did not multihome to different AS. Ok, that is where my mental disconnect came from. I saw the word multihomed and took that to mean homed to two different providers, not dual connections to the same. Such arrangements are not uncommon. Indeed. We do that in a couple of places, too.
Re: IPv6 Routing table will be bloated?
On Tue, 26 Oct 2010 12:19:30 -0500 Jack Bates jba...@brightok.net wrote: On 10/26/2010 12:04 PM, Nick Hilliard wrote: In practice, the RIRs are implementing sparse allocation which makes it possible to aggregate subsequent allocations. I.e. not as bad as it may seem. Except, if you are given bare minimums, and you are assigning out to subtending ISPs bare minimums, Why aren't those subtending ISPs getting their own PI (/32s)? those subtending ISPs will end up with multiple networks. Some of them are BGP speakers. I can't use sparse allocation because I was given minimum space and not the HD-Ratio threshold space. ARIN, RIPE and AfriNIC, for example, allocate on /29 boundaries. So if you get an initial allocation of /32, then find you need more, your subsequent allocations will be taken from the same /29, allowing aggregation up to /29. My minimum /30 allocation per ARIN met a /27 in HD-Ratio thresholds. To not be given the threshold space means no reservations for subtending ISPs, no room for subtending ISPs to grow, and multiple assignments. If ARIN only does /29 boundaries, I'll also be getting multiple /29's, and not just working within a /27 per the HD-Ratio guidelines. It's the mixed viewpoint that is the problem. HD-Ratio is useless as a justification and as a metric which promotes route conservation/aggregation if it is not used for initial allocations. Initial allocations (including those handed out to subtending ISPs) should all be as large as the immediate use HD Ratio permits. ie, If you are immediately assigning X /56 blocks, your assignment should have a length one less than the highest threshold you crossed. To assign any less is to constrain the assignments, not allow for growth, and to increase routing table size. It also circumvents and completely destroys the concept of HD Ratio (as the initial assignments all are well in excess of the thresholds for requesting much larger blocks). Jack
Re: IPv6 Routing table will be bloated?
On Tue, 26 Oct 2010 16:25:39 -0400 Scott Reed sr...@nwwnet.net wrote: Why would the assumption be the ISP = knowledgeable or even caring about RIRs, etc.? When I started my ISP 6 years ago I knew someone issued IP addresses to my upstream provider, but I really didn't care who that was. The upstream took care of everything related to getting and assigning addresses as far as I was concerned. Even when I changed upstream providers they took care of the addresses. It was at that time I realized I need to learn more about the whole IP address assignment process so I wouldn't have to renumber next time I changed providers. I dug far enough to find that my ISP was not big enough to get an assignment and the required fee was more than the cost to renumber, so I didn't look any farther. So, as a log of start-ups and small businesses do, I learned enough to make what I needed work, but not everything that may have been beneficial. So maybe to state the obvious, IPv4 != IPv6, and therefore in Jack's situation something different needs to be done, such as those ISPs learning about RIRs, LIRs etc. sooner rather than later. On 10/26/2010 3:20 PM, George Bonser wrote: -Original Message- From: Jack Bates [mailto:jba...@brightok.net] Sent: Tuesday, October 26, 2010 11:23 AM To: Randy Carpenter Cc: nanog@nanog.org Subject: Re: IPv6 Routing table will be bloated? On 10/26/2010 1:01 PM, Randy Carpenter wrote: Wait... If you are issuing space to ISPs that are multihomed, they should be getting their own addresses. Even if they aren't multihomed, they should probably be getting their own addresses. Why would you be supplying them with address space if they are an ISP? Because they are my customer. They don't know much about RIRs, paying membership fees, etc. They just know they want address space, and I provide that. If they are ISPs and don't know much about RIRs, can you please name them and provide their ASNs ... oh, wait ... they won't have an ASN if they don't know about RIRs and fees and such. Something isn't passing the smell test here. -- Scott Reed Owner NewWays Networking, LLC Wireless Networking Network Design, Installation and Administration Mikrotik Advanced Certified www.nwwnet.net (765) 855-1060
Re: IPv6 Routing table will be bloated?
I think APNIC has a policy that defines the minimum IPv6 allocation based on your current IPv4 allocation/usage. This would fix the problem? - Original Message - From: Randy Carpenter rcar...@network1.net To: Nick Hilliard n...@foobar.org Cc: nanog@nanog.org Sent: Wednesday, 27 October, 2010 6:31:18 AM Subject: Re: IPv6 Routing table will be bloated? I think ARIN is now doing sparse allocations on /28 boundaries. My personal opinion is that it should be even more sparse, and that allocations should be done on nibble boundaries. Any reasonably-sized ISP should get at least a /28. I deal with many small-ish ISPs, and most are 5,000-10,000 users. Those are probably served by a /32 for quite some time. When you get into the ones that are 20,000-50,000, it gets tricker to deal with. Those should get a /28. The mega-ISPs should get a /24, or even a /20. Another problem is that the allocations from IANA to the RIRs are too small to begin with. If there are 5 RIRs, why does there have to be so much fragmentation? It is too late for that, though. Anyway, I think there are some proposals floating around (Owen? ;-) ) That would make the /32,/28,/24 (nibble boundary) idea into policy. We'll have to wait and see what happens.
Re: IPv6 Routing table will be bloated?
It would be nice as a start, but does not really take into consideration future expansion needs. I would think that you could draw some parallels, though. Something like: v4 /16 ~ v6 /32 v4 /12 ~ v6 /28 v4 /8 ~ v6 /24 I know it we don't want to equate v4 and v6, but it may help as a guideline for the size of the customer base. -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 - Original Message - I think APNIC has a policy that defines the minimum IPv6 allocation based on your current IPv4 allocation/usage. This would fix the problem? - Original Message - From: Randy Carpenter rcar...@network1.net To: Nick Hilliard n...@foobar.org Cc: nanog@nanog.org Sent: Wednesday, 27 October, 2010 6:31:18 AM Subject: Re: IPv6 Routing table will be bloated? I think ARIN is now doing sparse allocations on /28 boundaries. My personal opinion is that it should be even more sparse, and that allocations should be done on nibble boundaries. Any reasonably-sized ISP should get at least a /28. I deal with many small-ish ISPs, and most are 5,000-10,000 users. Those are probably served by a /32 for quite some time. When you get into the ones that are 20,000-50,000, it gets tricker to deal with. Those should get a /28. The mega-ISPs should get a /24, or even a /20. Another problem is that the allocations from IANA to the RIRs are too small to begin with. If there are 5 RIRs, why does there have to be so much fragmentation? It is too late for that, though. Anyway, I think there are some proposals floating around (Owen? ;-) ) That would make the /32,/28,/24 (nibble boundary) idea into policy. We'll have to wait and see what happens.
Re: IPv6 Routing table will be bloated?
Yes indeed, but you don't have to justify much if you only ask for the minimum, if you want more you need to ask... Also, and this I like less, your membership is calculated from the number of IPs you have... I think in short $$=max(1180x1.3(log2(Addresses in /32)-8),Feev6 = 1180x1.3(log2(Addresses in /56)-22) http://www.apnic.net/services/apply-for-resources/check-your-eligibility/check-ipv6 http://www.apnic.net/services/become-a-member/how-much-does-it-cost - Original Message - From: Randy Carpenter rcar...@network1.net To: Franck Martin fra...@genius.com Cc: nanog@nanog.org, Nick Hilliard n...@foobar.org Sent: Wednesday, 27 October, 2010 10:48:13 AM Subject: Re: IPv6 Routing table will be bloated? It would be nice as a start, but does not really take into consideration future expansion needs. I would think that you could draw some parallels, though. Something like: v4 /16 ~ v6 /32 v4 /12 ~ v6 /28 v4 /8 ~ v6 /24 I know it we don't want to equate v4 and v6, but it may help as a guideline for the size of the customer base.
Re: IPv6 Routing table will be bloated?
It's very interesting to me that wee keep discussing RIRs other than ARIN when talking about allocation policies and issues for NANOG. The NA in NANOG puts the vast majority of it within the ARIN service region. The only other RIR which has territory within NA has not even been mentioned until now and that is LACNIC. (I'm afraid I am not yet familiar with their current IPv6 policies or practices). Owen On Oct 26, 2010, at 3:00 PM, Franck Martin wrote: Yes indeed, but you don't have to justify much if you only ask for the minimum, if you want more you need to ask... Also, and this I like less, your membership is calculated from the number of IPs you have... I think in short $$=max(1180x1.3(log2(Addresses in /32)-8),Feev6 = 1180x1.3(log2(Addresses in /56)-22) http://www.apnic.net/services/apply-for-resources/check-your-eligibility/check-ipv6 http://www.apnic.net/services/become-a-member/how-much-does-it-cost - Original Message - From: Randy Carpenter rcar...@network1.net To: Franck Martin fra...@genius.com Cc: nanog@nanog.org, Nick Hilliard n...@foobar.org Sent: Wednesday, 27 October, 2010 10:48:13 AM Subject: Re: IPv6 Routing table will be bloated? It would be nice as a start, but does not really take into consideration future expansion needs. I would think that you could draw some parallels, though. Something like: v4 /16 ~ v6 /32 v4 /12 ~ v6 /28 v4 /8 ~ v6 /24 I know it we don't want to equate v4 and v6, but it may help as a guideline for the size of the customer base.
Re: IPv6 Routing table will be bloated?
- Original Message - From: Owen DeLong o...@delong.com To: Franck Martin fra...@genius.com Cc: Randy Carpenter rcar...@network1.net, nanog@nanog.org Sent: Wednesday, 27 October, 2010 11:48:58 AM Subject: Re: IPv6 Routing table will be bloated? It's very interesting to me that wee keep discussing RIRs other than ARIN when talking about allocation policies and issues for NANOG. The NA in NANOG puts the vast majority of it within the ARIN service region. The only other RIR which has territory within NA has not even been mentioned until now and that is LACNIC. (I'm afraid I am not yet familiar with their current IPv6 policies or practices). Cute but not too bright The Oracle (The Matrix)
Re: Tools for teaching users online safety
On Oct 25, 2010, at 6:13 PM, Alex Thurlow wrote: I'm trying to find out if there are currently any resources available for teaching people how to be safe online. As in, how to not get a virus, how to pick out phishing emails, how to recognize scams. I'm sure everyone on this list knows these things, but a lot of end users don't. I'm trying to find a way to teach these things to people who aren't too technically savvy. It seems to me that the fewer end users that have issues, the easier our lives will be. So what I'm trying to figure out is, is there a good site or set of sites for this stuff, or is there anyone out there interested in helping to build a unified list of instructions, videos, etc. for all this? http://staysafeonline.org/ has recently emerged as the primary site for all of that kind of information, supported by DHS and a lot of big companies (including many who send people to NANOG meetings.)
Re: IPv6 Routing table will be bloated?
On Tue, Oct 26, 2010 at 05:48:13PM -0400, Randy Carpenter wrote: Someone who Randy didn't attribute wrote: I think APNIC has a policy that defines the minimum IPv6 allocation based on your current IPv4 allocation/usage. This would fix the problem? It would be nice as a start, but does not really take into consideration future expansion needs. I would think that you could draw some parallels, though. Something like: v4 /16 ~ v6 /32 v4 /12 ~ v6 /28 v4 /8 ~ v6 /24 I know it we don't want to equate v4 and v6, but it may help as a guideline for the size of the customer base. I don't think it's a particularly good metric, either, because it doesn't take into account the conversion rate of IPv4 to IPv6 addresses, which is wildly different in different networks. Fer instance, $JOB[-1] is a colo/hosting business, with a fair chunk of IPv4 allocated, and the standard IPv6 /32. I did the initial IPv6 address plan, and I'm pretty confident in saying that they'll *never* need any more than that /32 of IPv6, because their business model means that they pack their /64s relatively (hah!) densely (typically there's at least one /24 of IPv4 per /64 of IPv6). However, anyone doing network access is likely to be replacing an IPv4 /32 with an IPv6 /48, which results in a lot more address space usage. Direct conversion between IPv4 and IPv6 will either result in many places being starved of IPv6 (very bad, as the OP of this thread pointed out), or space will be massively overallocated (also, not real hot). - Matt
Re: IPv6 Routing table will be bloated?
So, the best that I can tell (still not through debating with RIR), the IPv6 routing table will see lots of bloat. 96 more bits, no magic
Re: Tools for teaching users online safety
Also the FTC has set up a comprehensive site to protect kids, including a guide for parents on kid's use of social networks. http://www.onguardonline.gov/ j On Tue, Oct 26, 2010 at 8:04 PM, J.D. Falk jdfalk-li...@cybernothing.orgwrote: On Oct 25, 2010, at 6:13 PM, Alex Thurlow wrote: I'm trying to find out if there are currently any resources available for teaching people how to be safe online. As in, how to not get a virus, how to pick out phishing emails, how to recognize scams. I'm sure everyone on this list knows these things, but a lot of end users don't. I'm trying to find a way to teach these things to people who aren't too technically savvy. It seems to me that the fewer end users that have issues, the easier our lives will be. So what I'm trying to figure out is, is there a good site or set of sites for this stuff, or is there anyone out there interested in helping to build a unified list of instructions, videos, etc. for all this? http://staysafeonline.org/ has recently emerged as the primary site for all of that kind of information, supported by DHS and a lot of big companies (including many who send people to NANOG meetings.) -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com Secretary - ISOC-NY - http://isoc-ny.org ---
