- NANOG - lists.nanog.org

<Help - Unable to builld a IP-SEC VPN on a Cisco ASA 5520>
by Michael Ruiz 08 Oct '09

08 Oct '09

Group, I am stuck like chuck. We are unable to activate a VPN in one of the virtual firewall context. Under the crypto commands, none of the IP-sec are available. Any help on this would be appreciated. Version we running is 8.0(4) Michael Ruiz mruiz(a)telwestservices.com <mailto::mruiz@telwestservices.com>

8 7

Re: ISP customer assignments
by Dan White 08 Oct '09

08 Oct '09

On 05/10/09 22:28 -0400, Ricky Beam wrote: > On Mon, 05 Oct 2009 17:13:37 -0400, Dan White <dwhite(a)olp.net> wrote: >> I don't understand. You're saying you have overlapping class boundaries >> in your network? > > No. What I'm saying is IPv6 is supposed to be the new, ground-breaking, > unimaginably huge *classless* network. Yet, 2 hours into day one, a > classful boundary has already been woven into it's DNA. Saying it's I would disagree. IPv6 is designed around class boundaries which, in my understanding, are: A layer two network gets assigned a /64 A customer gets assigned a /48 An ISP gets assigned a /32 (unless they need more) > classless because routing logic doesn't care is pure bull. In order for > the most basic, fundamental, part (the magic -- holy grail -- address > autoconfig) to function, the network has to be a minimum of /64. Even > when the reason for that limit -- using one's MAC to form a (supposedly) > unique address without having to consult with anything or fire off a > single packet -- has long bit the dust; privacy extensions generate > addresses at random and have to take steps to avoid address collisions, > so continuing to cling to "it has to be 64bits" is infuriating. IPv6 provides you the opportunity to design your network around your layer two needs, not limited by restrictive layer 3 subnetting needs. If your complaint is that all devices in a /64 are going to see IPv6 broadcast/multicast packets from the rest of the devices in that subnet, then don't assign 2^64 devices to that subnet. I still don't understand why its infuriating to you, but I can certainly tell that it is. -- Dan White BTC Broadband

4 3

Turkish Networks related questions..
by Mehmet Akcin 07 Oct '09

07 Oct '09

I have got few questions regarding Turkish ISPs, networks, could someone from Turkey possibly contact me offlist please? thank you. -- Mehmet Akcin Blog: http://www.mehmetakcin.com E-mail: mehmet(a)akcin.net

1 0

Telus BGP/ACL contact
by Jason Lixfeld 07 Oct '09

07 Oct '09

I'm looking for a Telus individual who might be able to adjust a prefix list for me. Our sales rep no longer works for Telus and it's after 5pm here, so no account managers are available to help me expedite this request. The NOC insists that there's nothing they can do unless I have something from my account person and unfortunately this is relatively time sensitive. Thanks in advance.

1 0

RE: <Help - Unable to builld a IP-SEC VPN on a Cisco ASA 5520>
by Tillinger, Steve 07 Oct '09

07 Oct '09

IPsec isn't available when in multiple context mode. -----Original Message----- From: Michael Ruiz [mailto:mruiz@telwestservices.com] Sent: Wednesday, October 07, 2009 12:56 PM To: nanog(a)nanog.org Subject: <Help - Unable to builld a IP-SEC VPN on a Cisco ASA 5520> Group, I am stuck like chuck. We are unable to activate a VPN in one of the virtual firewall context. Under the crypto commands, none of the IP-sec are available. Any help on this would be appreciated. Version we running is 8.0(4) Michael Ruiz mruiz(a)telwestservices.com <mailto::mruiz@telwestservices.com> "This communication is intended solely for the addressee and is confidential and not for third party unauthorized distribution"

2 1

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