October 2009 - Test - lists.nanog.org

Re: Dutch ISPs to collaborate and take responsibility
by Robert Bonomi 07 Oct '09

07 Oct '09

> From nanog-bounces+bonomi=mail.r-bonomi.com(a)nanog.org Wed Oct 7 06:18:24 2009 > Date: Wed, 07 Oct 2009 18:17:57 +0700 > From: Dave Temkin <davet1(a)gmail.com> > To: Alexander Harrowell <a.harrowell(a)gmail.com> > Subject: Re: Dutch ISPs to collaborate and take responsibility > Cc: nanog(a)nanog.org > > Alexander Harrowell wrote: > > On Wednesday 07 October 2009 00:27:55 Joe Greco wrote: > > > > > >> Assuming that the existence of an infected PC in the mix translates to > >> some sort of inability to make a 911 call correctly is, however, simply > >> irresponsible, and at some point, is probably asking for trouble. > >> > >> ... JG > >> > > > > Also, someone mentioned that the FCC doesn't in fact mandate that PSTN > > terminals should be able to make emergency calls even if formally disconnected > > and asked about cellular. > > > > The opposite is true about GSM and its descendants; whether or not you're a > > valid roamer for the network you're talking to, have a prepaid balance, have > > paid your bill, you must be able to make emergency calls. Similarly, even if > > no SIM card is present, the device should register with the network as > > "limited service" - i.e. emergency only. > > > > > The FCC generally doesn't come into play when you're talking about ILEC > telephone service except at a very high level. In California, by PUC > regulation telephone companies are required to allow access to 911 so > long as there is copper in the facility and it was, at any time, active > with any sort of phone service. "Not exactly". They are required to do it only 'to the extent permitted by existing facilities'. To wit, if they need that wire pair to provide service (say, an additional line) to a paying customer, they _can_ physically disconnct the 'inactive account' premises, and hook up the new paying account to that pair. On occasion, telcos are known to re-use the pair, by just hooking the new customer onto it, _without_ pulling the bridge clips at the 'multiple' where the old custmer was connected. This leads to all sorts of messes. the 'non- customer' discovers dial-tone on the pair and starts using it. Calls are being made which the _real_ customer didn't make, which leads to real arguments with the billing department. Then, the customer picks up their phone, and instead of getting dial tone, discovers a conversation _in_progress_ on the line -- when _nobody_else_ at their place is on the phone. Strangely, the parties to that conversation refuse to identify themselves, and one of them is _really_ anxious to terminate that call, so you can use "your" line. I, personally, have been through this more than once, in older, high-density housing neighborhoods.

1 0

Practical numbers for IPv6 allocations
by Doug Barton 07 Oct '09

07 Oct '09

[ I normally don't say this, but please reply to the list only, thanks. ] I've been a member of the "let's not assume the IPv6 space is infinite" school from day 1, even though I feel like I have a pretty solid grasp of the math. Others have alluded to some of the reasons why I have concerns about this, but they mostly revolve around the concepts that the address space is not actually flat (i.e., it's going to be carved up and handed out to RIRs, LIRs, companies, individuals, etc.) and that both the people making the requests and the people doing the allocations have a WIDE (pardon the pun) variety of motivations, not all of which are centered around the greater good. I'm also concerned that the two main pillars of what I semi-jokingly refer to as the "profligate" school of IPv6 allocation actually conflict with one another (even if they both had valid major premises, which I don't think they do). On the one hand people say, "The address space is so huge, we should allocate and assign with a 50-100 year time horizon" and on the other they say, "The address space is so huge, even if we screw up 2000::/3 we have 7 more bites at the apple." I DO believe that the space is large enough to make allocation policies with a long time horizon, but relying on "trying again" if we screw up the first time has a lot of costs that are currently undefined, and should not be assumed to be trivial. It also ignores the fact that if we reduce the pool of /3s because we do something stupid with the first one we allocate from it reduces our opportunities to do "cool things" with the other 7 that we haven't even thought of yet. In regards to the first of the "profligate" arguments, the idea that we can do anything now that will actually have even a 25 year horizon is naively optimistic at best. It ignores the day-to-day realities of corporate mergers and acquisitions, residential customers changing residences and/or ISPs, the need for PI space, etc. IPv6 is not a "set it and forget it" tool any more than IPv4 is because a lot of the same realities apply to it. You also have to keep in mind that even if we could come up with a theoretically "perfect" address allocation scheme at minimum the existing space is going to be carved up 5 ways for each of the RIRs to implement. (When I was at IANA I actually proposed dividing it along the 8 /6 boundaries, which is sort of what has happened subsequently if you notice the allocations at 2400::/12 to APNIC, 2800::/12 to LACNIC and 2c00::/12 to AfriNIC.) Since it's not germane to NANOG I will avoid rehashing the "why RA and 64-bit host IDs were bad ideas from the start" argument. :) In the following I'm assuming that you're familiar with the fact that staying on the 4-byte boundaries makes sense because it makes reverse DNS delegation easier. It also makes the math easier. As a practical matter we're "stuck" with /64 as the smallest possible network we can reliably assign. A /60 contains 16 /64s, which personally I think is more than enough for a residential customer, even taking a "long view" into consideration. The last time I looked into this there were several ISPs in Japan who were assigning /60s to their residential users with good success. OTOH, a /56 contains 256 /64s, which is way WAY more than enough for a residential user. The idea that a residential user needs a full /48 (65,536 /64s) is absurd. OTOH, assigning a /48 to even a fairly large commercial customer is perfectly reasonable. This would give them 256 /56 networks (which would in turn have 256 /64 networks) which should be plenty to handle the problems of multiple campuses with multiple subnets, etc. So let's assume that we'll take /56 as the standard unit of assignment to residential customers, and /48 as the standard unit of assignment to commercial customers. A /32 has 65,536 /48s in it. If your business was focused mainly on commercial customers that's not a very big pool. OTOH if your business was focused primarily on residential customers you'd have 16,777,216 /56s to work with. That's enough for even a very large regional ISP. One could also easily imagine a model where out of a /32 you carve out one /34 for /56 assignments (4,194,304) and use the other 3/4ths of the space for /48s (49,152). A really large ("national" or even "global") ISP would obviously need more space if they were going to intelligently divide up addresses on a regional basis. A /28 would have 16 /32s which should be enough for even a "very large" ISP, but let's really make sure that we cover the bases and go /24 (256 /32s). Even if you assume splitting that address space in half, that's 2.147483e+09 (approximately 2,147,483,000) /56s, and 8,388,608 /48s. There are roughly 2,097,152 /24s in 2000::/3 (I say "roughly" because I'm ignoring space that's already been carved out, like 6to4, etc.), or 262,144 /24s per /6, or 67,108,864 /32s per /6. Which means that yes, we really do have "a lot" of space to work with. I also think it means that even with "a lot" of space there is no point in wasting it with foolish allocation policies that give out way more space than is realistically necessary just "because we can." I've ignored PI space up till now but I think it's reasonable for there to be a midpoint for PI somewhere between /48 and /32. Personally I think that a /40 has a nice sound to it. That's 256 /48 networks. I don't see any reason why the RIRs couldn't also agree to a /36, which would be 4,096 /48s. Even I don't see any reason why they should mess around with numbers like /41 or /43. To get back to the question that started the original thread, if I were the one who was requesting an IPv6 allocation I would use the following formula: 1 /56 per # of residential customers expected in 10 years + 1 /48 per # of business customers expected in 10 years Then assuming your current numbers are roughly 1/16th of what you hope they'll be in 10 years; when actually handing out addresses I'd give out the first /60 from each /56 to the residential customers. That way if you need to you can go back and chop up those /56s. I'd also start off handing out the first /48 out of every /44 to my commercial customers. That way they will have room to expand painlessly. This is sort of a bastardized version of the "sparse allocation" model that the RIRs have promoted. (Obviously the 1/16th number was chosen for convenience, but hopefully you get the idea of what I'm going for here.) I realize that this is quite long, so if you've gotten this far, congratulations! I hope it was useful. Doug -- Food for thought is no substitute for the real thing. -- Walt Kelly, "Potluck Pogo"

8 9

RE: Dutch ISPs to collaborate and take responsibility for bottedclients
by Robert Bonomi 06 Oct '09

06 Oct '09

> > > -----Original Message----- > > From: Eugeniu Patrascu [mailto:eugen@imacandi.net] > > Sent: Tuesday, October 06, 2009 4:20 AM > > To: Gadi Evron > > Cc: NANOG > > Subject: Re: Dutch ISPs to collaborate and take responsibility for > bottedclients > . > > > > > I think the need for someone being able to call 911 from their VoIP > > outweighs your right to claim that they should be disconnected from the > > Internet. > > I believe the FCC requires even deactivated phones to be able to reach 911. > Can't confirm, fcc.gov is down. Authoritatively *NOT* true for hard-wire landlines in the U.S. Cellular may, and I believe _is_, be a different story.

1 0

IPv6 peering between Internet2 and Hurricane Electric
by Florian Weimer 06 Oct '09

06 Oct '09

It seems to be down, based on <http://routerproxy.grnoc.iu.edu/internet2/> and trying to get a traceroute to he.net/2001:470:0:76::2 from the SEAT location. BGP seems to be up, though. Shouldn't this cause quite a few problems for Internet2 downstreams? (We received a report from an academic site in Brazil that some security.debian.org IPv6 instances are inaccessible, that's why I looked.) What's the best way to help the SPs involved to get this resolved?

1 1

ISP customer assignments
by Brian Johnson 06 Oct '09

06 Oct '09

>From what I can tell from an ISP perspective, the design of IPv6 is for assignment of a /64 to an end user. Is this correct? Is this how it is currently being done? If not, where am I going wrong? Thank you. - Brian

20 30

RE: ISP customer assignments
by TJ 06 Oct '09

06 Oct '09

-----Original Message----- From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] <Snip - good points all> > Most of those concerns are in fact mitigated by a well implemented Privacy > implementation Which is why I started off by mentioning RFC4191. ;) -----End Original Message----- And Vista/Win7/etc. make it even more interesting by not doing EUI64 at all. ... Hopefully they have more entropic 'random' values as well ... /TJ

1 0

please leak piratebay prefix 194.71.107.0/24
by Sven Olaf Kamphuis 06 Oct '09

06 Oct '09

we currently announce 194.71.107.0/24, unfortunately some of our carriers have been threattened by the illegal entertainment kartell mafia and dont really feel like relaying this prefix for us. if you do have this prefix over one of our peerings as i know many of you do, feel free to accidentially leak it to the rest of the world until something better is worked out :P (in a later stadium the old DCP AS is planned to be behind AS34109 again on its own, this is a temporary workaround) origin: AS34109 (CB3ROB / CYBERBUNKER) prefix: 194.71.107.0/24 action: leak :P if you want to "pick up" the piratebay prefix for your eyeballs you can do so by setting up peering with us at NL-IX (noc(a)cb3rob.net) or obtain it from several of our larger peers. -- Sven Olaf Kamphuis CB3ROB DataServices Phone: +31/87-8747479 Skype: CB3ROB MSN: sven(a)cb3rob.net C.V.: http://www.linkedin.com/in/cb3rob 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.

1 0

Re: ISP customer assignments
by Chris Owen 05 Oct '09

05 Oct '09

On Oct 5, 2009, at 1:43 PM, Wayne E. Bouchard wrote: > Whenever you declare something to be "inexhasutable" all you do is > increase demand. Eventually you reach a point where you realize that > there is, in fact, a limit to the inexhaustable resource. This is where I think there is a major disconnect on IPv6. The size of the pool is just so large that people just can't wrap their heads around it. 2^128 is enough space for every man, woman and child on the planet to have around 4 billion /64s to themselves. Even if we assume everyone might possibly need say 10 /64s per person that still means we are covered until the population hits around 2,600,000,000,000,000,000. Chris ------------------------------------------------------------------------- Chris Owen - Garden City (620) 275-1900 - Lottery (noun): President - Wichita (316) 858-3000 - A stupidity tax Hubris Communications Inc www.hubris.net -------------------------------------------------------------------------

6 6

FairPoint New England Internet Access issues.
by Davis, Bill (Manchester, NH) 05 Oct '09

05 Oct '09

Oct 2, 2009: Verizon identified it largest CORE Juniper router was creating issues for all of it peering points to New York and Boston having said that all of FairPoint's DIA, DSL, Fast customer had intermittent issues accessing the internet partial service was restored after Verizon reroute part of FairPoint traffic. Verizon was able to replace the Juniper router and restore full service around 1:45 PM EDT October 3rd 2009. Bill Davis William P. Davis - Director IT Network FairPoint Communications | 900 Elm St., Manchester, NH 03101 | bdavis(a)fairpoint.com <mailto:acouture@Fairpoint.com> 620-339-4786 office | 309-696-0299 Cell _______________________________________________________________________ This e-mail message and its attachments are for the sole use of the intended recipients. They may contain confidential information, legally privileged information or other information subject to legal restrictions. If you are not the intended recipient of this message, please do not read, copy, use or disclose this message or its attachments, notify the sender by replying to this message and delete or destroy all copies of this message and attachments in all media.

1 0

operations contact @ facebook?
by Leland Vandervort 05 Oct '09

05 Oct '09

Hi All, Would anyone happen to have an operations contact at Facebook by anychance? Our systems are being overwhelmed by a facebook application that we were neither aware of nor condoned. Thanks in advance. Leland Vandervort Director, Technical Operations Gandi SAS Paris t: +33 1 70 39 37 59 m: +33 6 31 15 15 07

9 12