Re: AS3.196 [91.213.29.0/24] IM-AS Info-Media Ltd
It seems Team Cymru needs to update its whois db to use 4-byte ASNs and remove AS_TRANS (23456) --Ricardo On Oct 12, 2009, at 11:41 PM, Paul Ferguson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm a bit confused (nothing really new here) with this BGP announcement, but following up on some cyber crime activity I stumbled on this: [Querying v4.whois.cymru.com] [v4.whois.cymru.com] AS | IP | AS Name 23456 | 91.213.29.250| -Reserved AS- Is this legitimate? route-views2.routeviews.org sho ip bgp 91.213.29.250 BGP routing table entry for 91.213.29.0/24 Paths: (42 available, best #33, table Default-IP-Routing-Table) Not advertised to any peer 6939 9002 40965 196804 216.218.252.164 from 216.218.252.164 (216.218.252.164) Origin IGP, localpref 100, valid, external Last update: Mon Oct 12 17:18:08 2009 13030 9002 40965 196804 213.144.128.203 from 213.144.128.203 (213.144.128.203) Origin IGP, metric 1, localpref 100, valid, external Community: 13030:1 13030:1016 Last update: Mon Oct 12 13:10:14 2009 14608 4323 9002 40965 196804 209.161.175.4 from 209.161.175.4 (209.161.175.4) Origin IGP, localpref 100, valid, external Community: no-export Last update: Mon Oct 12 08:06:19 2009 286 9002 40965 196804 134.222.87.3 from 134.222.87.3 (134.222.85.108) Origin IGP, metric 0, localpref 100, valid, external Community: 286:18 286:19 286:28 286:29 286:800 286:888 286:3044 286:4019 Last update: Sat Oct 10 22:44:50 2009 1299 3549 9002 40965 196804 213.248.83.252 from 213.248.83.252 (213.248.83.252) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 15:43:18 2009 3303 9002 40965 196804 164.128.32.11 from 164.128.32.11 (164.128.32.11) Origin IGP, localpref 100, valid, external Community: 1120:2 3303:1004 3303:1006 3303:3056 Last update: Thu Oct 8 15:06:42 2009 2905 702 9002 40965 196804 196.7.106.245 from 196.7.106.245 (196.7.106.245) Origin IGP, metric 0, localpref 100, valid, external Last update: Thu Oct 8 15:42:42 2009 31500 3267 9002 40965 196804 95.140.80.254 from 95.140.80.254 (1.0.0.10) Origin IGP, metric 0, localpref 100, valid, external Last update: Tue Oct 13 00:33:35 2009 1221 4637 3549 9002 40965 196804 203.62.252.186 from 203.62.252.186 (203.62.252.186) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:32 2009 5056 1239 3549 9002 40965 196804 167.142.3.6 from 167.142.3.6 (167.142.225.101) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 15:10:31 2009 7660 2516 3549 9002 40965 196804 203.181.248.168 from 203.181.248.168 (203.181.248.168) Origin IGP, localpref 100, valid, external Community: 2516:1030 Last update: Thu Oct 8 14:44:01 2009 6762 3549 9002 40965 196804 195.22.216.188 from 195.22.216.188 (195.22.216.188) Origin IGP, metric 100, localpref 100, valid, external Community: 6762:31 Last update: Thu Oct 8 14:43:28 2009 16150 9002 40965 196804 217.75.96.60 from 217.75.96.60 (217.75.96.60) Origin IGP, metric 0, localpref 100, valid, external Community: 16150:63392 16150:65215 16150:65320 Last update: Thu Oct 8 14:43:26 2009 6453 3549 9002 40965 196804 207.45.223.244 from 207.45.223.244 (66.110.0.124) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:25 2009 2152 11164 9002 40965 196804 137.164.16.12 from 137.164.16.12 (137.164.16.196) Origin IGP, localpref 100, valid, external Community: 2152:65299 2152:65506 11164:1130 11164:7880 Last update: Sat Oct 10 13:52:50 2009 6453 3549 9002 40965 196804 195.219.96.239 from 195.219.96.239 (195.219.96.239) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:22 2009 3277 3267 9002 40965 196804 194.85.4.55 from 194.85.4.55 (194.85.4.16) Origin IGP, localpref 100, valid, external Community: 3277:3267 3277:65321 3277:65323 Last update: Thu Oct 8 14:43:51 2009 852 3561 9002 40965 196804 154.11.98.225 from 154.11.98.225 (154.11.98.225) Origin IGP, metric 0, localpref 100, valid, external Community: 852:180 Last update: Thu Oct 8 14:43:21 2009 3356 9002 40965 40965 196804 4.69.184.193 from 4.69.184.193 (4.68.3.50) Origin IGP, metric 0, localpref 100, valid, external Community: 3356:2 3356:22 3356:100 3356:123 3356:507 3356:2076 65000:0 Last update: Tue Oct 13 06:09:59 2009 701 3549 9002 40965 196804 157.130.10.233 from 157.130.10.233 (137.39.3.60) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:48 2009 8492 9002 40965 196804 85.114.0.217 from 85.114.0.217 (85.114.0.2) Origin IGP, localpref 100, valid, external Community: 8492:1101 9002:0 9002:64677 Last update: Thu Oct 8 14:43:16 2009 5413 9002 40965 196804 62.72.136.2 from
Re: .se disappeared?
On Tue, Oct 13, 2009 at 12:23:46AM +0200, Hauke Lampe list+na...@hauke-lampe.de wrote a message of 53 lines which said: Even after a cache reload, the SOA record appears still bogus: Yes, even after a cold reboot, the data did not validate. But, this time, the problem was purely DNSSEC and was noticed only by people brave enough to validate. Too much haste in repairing probably. Unbound returns SERVFAIL instead. Fixed, now.
Re: IPv6 internet broken, Verizon route prefix length policy
On 13/10/2009, at 5:46 PM, Kevin Loch wrote: I think he was pointing out that extra routes due to slow start policies should not be a factor in v6. My guess is that is about half of the extra routes announced today, the other half being TE routes. You can pretty easily figure out how many advertised prefixes are intentional de-aggregates, and you can get a fairly good idea as to how many of them are for TE as well I expect, by looking for different AS paths. Someone mentioned some slides earlier in this thread by Vince Fuller at APRICOT early '07 that from memory have pretty good data on this. -- Nathan Ward
Re: AS3.196 [91.213.29.0/24] IM-AS Info-Media Ltd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So, is this the first usage of 4-byte ASNs by cyber criminals? :-) It would appear so. - - ferg On Mon, Oct 12, 2009 at 11:44 PM, Ricardo Oliveira rvel...@cs.ucla.edu wrote: It seems Team Cymru needs to update its whois db to use 4-byte ASNs and remove AS_TRANS (23456) --Ricardo On Oct 12, 2009, at 11:41 PM, Paul Ferguson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm a bit confused (nothing really new here) with this BGP announcement, but following up on some cyber crime activity I stumbled on this: [Querying v4.whois.cymru.com] [v4.whois.cymru.com] AS | IP | AS Name 23456 | 91.213.29.250| -Reserved AS- Is this legitimate? route-views2.routeviews.org sho ip bgp 91.213.29.250 BGP routing table entry for 91.213.29.0/24 Paths: (42 available, best #33, table Default-IP-Routing-Table) Not advertised to any peer 6939 9002 40965 196804 216.218.252.164 from 216.218.252.164 (216.218.252.164) Origin IGP, localpref 100, valid, external Last update: Mon Oct 12 17:18:08 2009 13030 9002 40965 196804 213.144.128.203 from 213.144.128.203 (213.144.128.203) Origin IGP, metric 1, localpref 100, valid, external Community: 13030:1 13030:1016 Last update: Mon Oct 12 13:10:14 2009 14608 4323 9002 40965 196804 209.161.175.4 from 209.161.175.4 (209.161.175.4) Origin IGP, localpref 100, valid, external Community: no-export Last update: Mon Oct 12 08:06:19 2009 286 9002 40965 196804 134.222.87.3 from 134.222.87.3 (134.222.85.108) Origin IGP, metric 0, localpref 100, valid, external Community: 286:18 286:19 286:28 286:29 286:800 286:888 286:3044 286:4019 Last update: Sat Oct 10 22:44:50 2009 1299 3549 9002 40965 196804 213.248.83.252 from 213.248.83.252 (213.248.83.252) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 15:43:18 2009 3303 9002 40965 196804 164.128.32.11 from 164.128.32.11 (164.128.32.11) Origin IGP, localpref 100, valid, external Community: 1120:2 3303:1004 3303:1006 3303:3056 Last update: Thu Oct 8 15:06:42 2009 2905 702 9002 40965 196804 196.7.106.245 from 196.7.106.245 (196.7.106.245) Origin IGP, metric 0, localpref 100, valid, external Last update: Thu Oct 8 15:42:42 2009 31500 3267 9002 40965 196804 95.140.80.254 from 95.140.80.254 (1.0.0.10) Origin IGP, metric 0, localpref 100, valid, external Last update: Tue Oct 13 00:33:35 2009 1221 4637 3549 9002 40965 196804 203.62.252.186 from 203.62.252.186 (203.62.252.186) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:32 2009 5056 1239 3549 9002 40965 196804 167.142.3.6 from 167.142.3.6 (167.142.225.101) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 15:10:31 2009 7660 2516 3549 9002 40965 196804 203.181.248.168 from 203.181.248.168 (203.181.248.168) Origin IGP, localpref 100, valid, external Community: 2516:1030 Last update: Thu Oct 8 14:44:01 2009 6762 3549 9002 40965 196804 195.22.216.188 from 195.22.216.188 (195.22.216.188) Origin IGP, metric 100, localpref 100, valid, external Community: 6762:31 Last update: Thu Oct 8 14:43:28 2009 16150 9002 40965 196804 217.75.96.60 from 217.75.96.60 (217.75.96.60) Origin IGP, metric 0, localpref 100, valid, external Community: 16150:63392 16150:65215 16150:65320 Last update: Thu Oct 8 14:43:26 2009 6453 3549 9002 40965 196804 207.45.223.244 from 207.45.223.244 (66.110.0.124) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:25 2009 2152 11164 9002 40965 196804 137.164.16.12 from 137.164.16.12 (137.164.16.196) Origin IGP, localpref 100, valid, external Community: 2152:65299 2152:65506 11164:1130 11164:7880 Last update: Sat Oct 10 13:52:50 2009 6453 3549 9002 40965 196804 195.219.96.239 from 195.219.96.239 (195.219.96.239) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:22 2009 3277 3267 9002 40965 196804 194.85.4.55 from 194.85.4.55 (194.85.4.16) Origin IGP, localpref 100, valid, external Community: 3277:3267 3277:65321 3277:65323 Last update: Thu Oct 8 14:43:51 2009 852 3561 9002 40965 196804 154.11.98.225 from 154.11.98.225 (154.11.98.225) Origin IGP, metric 0, localpref 100, valid, external Community: 852:180 Last update: Thu Oct 8 14:43:21 2009 3356 9002 40965 40965 196804 4.69.184.193 from 4.69.184.193 (4.68.3.50) Origin IGP, metric 0, localpref 100, valid, external Community: 3356:2 3356:22 3356:100 3356:123 3356:507 3356:2076 65000:0 Last update: Tue Oct 13 06:09:59 2009 701 3549 9002 40965 196804 157.130.10.233 from 157.130.10.233 (137.39.3.60) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:48 2009
RE: ISP customer assignments
-Original Message- From: Justin To go along with Dan's query from above, what are the preferred methods that other SPs are using to deploy IPv6 with non-IPv6-capable edge hardware? We too have a very limited number of dialup customers and will never sink another dollar in the product. Unfortunately I also have brand-new ADSL2+ hardware that doesn't support IPv6 and according to the vendors (Pannaway) never will. We also have CMTSs that don't support IPv6, even though they too are brand-new. Those CMTSs top out at DOCSIS 2.0 and the vendor decided not to allow IPv6 to the CPEs regardless of the underlying CM's IPv6 support or lack thereof (like Cisco allowed for example). Are providers implementing tunneling solutions? Pros/cons of the various solutions? My first (potentially ignorant) response would be to get your acquisitions people aligned with your business, and by that I mean they should be making a concerted effort to only buy IPv6 capable gear, especially when IPv6 is coming to you within that gears lifecycle. I guess your customers will need to tunnel, as long as you give them a public IP they have 6to4 (and possibly Teredo, tunnel broker) - but native is better.
Re: ISP customer assignments
Nathan Ward, please stand up. Adrian On Tue, Oct 13, 2009, TJ wrote: -Original Message- From: Justin To go along with Dan's query from above, what are the preferred methods that other SPs are using to deploy IPv6 with non-IPv6-capable edge hardware? We too have a very limited number of dialup customers and will never sink another dollar in the product. Unfortunately I also have brand-new ADSL2+ hardware that doesn't support IPv6 and according to the vendors (Pannaway) never will. We also have CMTSs that don't support IPv6, even though they too are brand-new. Those CMTSs top out at DOCSIS 2.0 and the vendor decided not to allow IPv6 to the CPEs regardless of the underlying CM's IPv6 support or lack thereof (like Cisco allowed for example). Are providers implementing tunneling solutions? Pros/cons of the various solutions? My first (potentially ignorant) response would be to get your acquisitions people aligned with your business, and by that I mean they should be making a concerted effort to only buy IPv6 capable gear, especially when IPv6 is coming to you within that gears lifecycle. I guess your customers will need to tunnel, as long as you give them a public IP they have 6to4 (and possibly Teredo, tunnel broker) - but native is better. -- - 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: .se disappeared?
Hi, .se statement: http://www.iis.se/en/2009/10/13/felaktig-dns-information/ Kind regards, ingo flaschberger
Re: ISP customer assignments
No idea, I haven't looked at that stuff in a while. But I would assume so, as it's easier to build a foundation than jumping straight to something difficult? Or did you learn calculus in grade school? Just askin' ;) Scott Mark Newton wrote: On 13/10/2009, at 2:02 PM, Scott Morris wrote: I happen to train people at CCIE level. I also happen to do consulting, implementation, and design work. In my training environment, there are all sorts of re-thinking of what/how things are being taught even within the confines of comparison to a lab environment. Does the CCNA exam still ask questions about RIP and classful addressing? Just askin' :-) - mark -- Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223
Re: .se disappeared?
On 13/10/2009 12:18, Ingo Flaschberger wrote: .se statement: http://www.iis.se/en/2009/10/13/felaktig-dns-information/ The internet's reply (sfw): http://pr0nbot.phetast.nu/src/iis_xzibit-1255422509.JPEG Nick
Re: ISP customer assignments
On 2009-10-13, at 07:39, Scott Morris wrote: No idea, I haven't looked at that stuff in a while. But I would assume so, as it's easier to build a foundation than jumping straight to something difficult? I've found RIP to be a reasonable way to teach the concept of a routing protocol, since the protocol is very simple and you can always close with don't ever use this. But teaching classful routing and addressing is just moronic. It's a foundation that nothing is built on any more, and makes no sense to teach outside of a history class. Or did you learn calculus in grade school? Just askin' ;) Yes, since you asked, but your presumption is faulty. Joe
Re: ISP customer assignments
While I may agree that teaching classful routing is stupid, the addressing part lets people start getting the concept of binary. While I'd love to think that people coming out of the school system have a grasp of simple mathematical skills, more and more I'm finding that's not the case.I wouldn't spend a LOT of time with it, and I certainly wouldn't LEAVE at classful addressing, but it's a foundational step. Why is the presumption faulty? If you did calculus, more power to you. However, you still needed a foundation before a pseudo-random collection of letters and numbers together would make any sense. ;) I learned long ago that not everyone can learn in the same fashion that I do. So there's a path to everything with foundations. Some people have a hard time subnetting IPv4 on varying boundaries. More people have a hard time subnetting IPv6 on varying boundaries. While I don't have a problem with either I have to find ways to fix those that do while teaching. And typically it's missing foundation skills. But anyway, I don't think that's the important part! My point was more about not assuming that just because someone is teaching that they don't have a realistic set of experiences to go with it as the poster from APNIC pointed out. Just my two cents, Scott Joe Abley wrote: On 2009-10-13, at 07:39, Scott Morris wrote: No idea, I haven't looked at that stuff in a while. But I would assume so, as it's easier to build a foundation than jumping straight to something difficult? I've found RIP to be a reasonable way to teach the concept of a routing protocol, since the protocol is very simple and you can always close with don't ever use this. But teaching classful routing and addressing is just moronic. It's a foundation that nothing is built on any more, and makes no sense to teach outside of a history class. Or did you learn calculus in grade school? Just askin' ;) Yes, since you asked, but your presumption is faulty. Joe
Re: ISP customer assignments
Ok, fair enough. I was working on the presumption not so much that it was simpler but more than it provided a logical structure. Having some framework to start with provides a base. True that binary is binary is binary... But rather than just an amorphous collection of x-number of bits, there's some initial rhyme and reason. Explaining that, getting buy in, and understanding the limitations therein will make the next progression to VLSM simpler to grasp. At least in my opinion. :) Scott Joe Abley wrote: On 2009-10-13, at 08:05, Scott Morris wrote: While I may agree that teaching classful routing is stupid, the addressing part lets people start getting the concept of binary. That's true of classless addressing, too. When students have problems with non-octet bit boundaries, that just means you start with mask lengths that are multiples of 8. While I'd love to think that people coming out of the school system have a grasp of simple mathematical skills, more and more I'm finding that's not the case.I wouldn't spend a LOT of time with it, and I certainly wouldn't LEAVE at classful addressing, but it's a foundational step. Why is the presumption faulty? You were suggesting that classful addressing is reasonable to teach because it's simpler. It's not simpler, and in a modern-day context it's just wrong. Joe
Re: ISP customer assignments
Heh - Every time I try to say something close to don't ever use this or not really used anymore WRT RIP I get a student or three that is using it, and in fact it is there only option due to certain vendors' choices of what routing protocols to support on certain classes of gear. /TJ ... really hoping those certain vendors choose OSPFv3 (or ISIS, I really don't care - anything instead of RIPng :P ) for IPv6. On Tue, Oct 13, 2009 at 7:53 AM, Joe Abley jab...@hopcount.ca wrote: On 2009-10-13, at 07:39, Scott Morris wrote: No idea, I haven't looked at that stuff in a while. But I would assume so, as it's easier to build a foundation than jumping straight to something difficult? I've found RIP to be a reasonable way to teach the concept of a routing protocol, since the protocol is very simple and you can always close with don't ever use this. But teaching classful routing and addressing is just moronic. It's a foundation that nothing is built on any more, and makes no sense to teach outside of a history class. Or did you learn calculus in grade school? Just askin' ;) Yes, since you asked, but your presumption is faulty. Joe -- /TJ
Re: ISP customer assignments
On Tue, 13 Oct 2009 07:39:46 EDT, Scott Morris said: No idea, I haven't looked at that stuff in a while. But I would assume so, as it's easier to build a foundation than jumping straight to something difficult? Unfortunately, classful addressing is a foundation for networking the same way Roman numerals were a foundation for arithmetic. Both are the way we used to do it, neither is relevant anymore, and once learned, both are bad habits that actively inhibit learning the more useful methods... And yes, as a matter of fact, I *did* start learning calculus in grade school. Have to admit that partial derivatives stumped me until middle school, though. pgpVX8PuwxRdX.pgp Description: PGP signature
Re: ISP customer assignments
Doug Barton wrote: Out of curiosity who is conducting this class and what was their rationale for using /127s? It's a GK class. The instructor seems to be fairly knowledgeable and has a lengthy history consulting on and deploying IPv6. The class seems to be geared much more towards enterprise though instead of service providers. That's very unfortunate considering that every one of the 15 people in this class either works for or contracts to a SP. Still the instructor has some SP knowledge so he fills in the blanks when possible. We're all thinking like SPs though and we ask the SP-oriented questions which usually helps us steer the course the direction we want. I wish GK and other training companies would start offering classes geared towards SPs. They could easily take the existing courseware, add a couple days at the end and interject useful SP info into the earlier days. All that extra info could be specifically aimed at SPs. He didn't really give much of a reason for the /127s yet. I think it's coming up in a later session. I think it basically boiled down to whether or not the customer would actually use anything bigger. I'll write back when we get into that discussion. Justin
Re: ISP customer assignments
On 13/10/09 15:33, Justin Shore wrote: He didn't really give much of a reason for the /127s yet. I think it's coming up in a later session. I think it basically boiled down to whether or not the customer would actually use anything bigger. I'll write back when we get into that discussion. Anything other than /64 removes the possibility of using privacy (aka temporary) addresses, enabled on Vista and above by default (net.ipv6.conf.all.use_tempaddr on Linux). For a single prefix a host may have by default up to 8 global unicast addresses - 1 EUI-64 and 7 privacy.
Re: ISP customer assignments
On 12/10/09 21:34 -0500, Justin Shore wrote: To go along with Dan's query from above, what are the preferred methods that other SPs are using to deploy IPv6 with non-IPv6-capable edge hardware? We too have a very limited number of dialup customers and will never sink another dollar in the product. Unfortunately I also have brand-new ADSL2+ hardware that doesn't support IPv6 and according to the vendors (Pannaway) never will. I don't recall if Pannaway is a layer 3 or layer 2 DSLAM, but we have a mix of Calix C7 (ATM) and Calix E5 (Ethernet) gear in our network. We're kinda in the same boat, but we expect to be able to gracefully transition to dual stacked IPv4/IPv6 without having to replace DSL modems, by reconfiguring the modems into bridged mode and leaving the layer 3 up to the customer's router. We're also in the process of budgeting for a new broadband aggregation router next year that will handle IPv6. Ask Pannaway if they can bridge traffic (either ATM PVC, or Ethernet QinQ/VLAN per subscriber) up to a broadband aggregator, like a Redback or Cisco. -- Dan White
Re: ISP customer assignments
George Michaelson wrote: As a point of view on this, a member of staff from APNIC was doing a Masters of IT in the last 3-4 years, and had classfull A/B/C addressing taught to her in the networks unit. She found it quite a struggle to convince the lecturer that reality had moved on and they had no idea about CIDR. I'm ok with teaching it to beginners to explain where we came from but that should be it. It should be made excruciatingly clear in the training that it's no longer done that way because we found a MUCH better way of doing things. That said I still occasionally refer to networks in classful terms and I can think of several network engineers who have years of enterprise experience that still don't understand CIDR. Justin
Re: IPv6 in the ARIN region
I contacted 209 yesterday (due to the ongoing Cogent/174 silliness) and it seems like they are willing to turn up customer-facing v6, but have made it a sales process (versus a technical request) and so that complicates things. -Dave On Tue, Oct 13, 2009 at 8:27 AM, Seth Mattinen se...@rollernet.us wrote: New thread: who will route the full IPv6 table? So far I'm seeing PI /48's out of 2620:0:/23 from: NTT, 2914 ATT, 7018 Sprint, 1239 and 6175 Hurricane, 6939 Level 3, 3356 Global Crossing, 3549 Qwest, 209 Did I miss anyone? Qwest only carries one route (out of 4 total) though, don't know if that's an exception or they only have one ARIN PI customer. ~Seth
Re: IPv6 in the ARIN region
We are running IPv6 over 209 currently. 2607:F8E8::/32 Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP http://uplogon.com | +1 906 774 4847 | ch...@uplogon.com David Temkin wrote: I contacted 209 yesterday (due to the ongoing Cogent/174 silliness) and it seems like they are willing to turn up customer-facing v6, but have made it a sales process (versus a technical request) and so that complicates things. -Dave On Tue, Oct 13, 2009 at 8:27 AM, Seth Mattinen se...@rollernet.us wrote: New thread: who will route the full IPv6 table? So far I'm seeing PI /48's out of 2620:0:/23 from: NTT, 2914 ATT, 7018 Sprint, 1239 and 6175 Hurricane, 6939 Level 3, 3356 Global Crossing, 3549 Qwest, 209 Did I miss anyone? Qwest only carries one route (out of 4 total) though, don't know if that's an exception or they only have one ARIN PI customer. ~Seth
RE: IPv6 in the ARIN region
-Original Message- From: Seth Mattinen [mailto:se...@rollernet.us] Sent: Tuesday, October 13, 2009 8:28 AM To: nanog@nanog.org Subject: IPv6 in the ARIN region New thread: who will route the full IPv6 table? So far I'm seeing PI /48's out of 2620:0:/23 from: NTT, 2914 ATT, 7018 Sprint, 1239 and 6175 Hurricane, 6939 Level 3, 3356 Global Crossing, 3549 Qwest, 209 You can add Time Warner, AS 4323, to the list. Regards, Mike
RE: IPv6 in the ARIN region
You can add TiNet AS3257 to the list. Ryan Werber Sr. Network Engineer Epik Networks -Original Message- From: Seth Mattinen [mailto:se...@rollernet.us] Sent: Tuesday, October 13, 2009 11:28 AM To: nanog@nanog.org Subject: IPv6 in the ARIN region New thread: who will route the full IPv6 table? So far I'm seeing PI /48's out of 2620:0:/23 from: NTT, 2914 ATT, 7018 Sprint, 1239 and 6175 Hurricane, 6939 Level 3, 3356 Global Crossing, 3549 Qwest, 209 Did I miss anyone? Qwest only carries one route (out of 4 total) though, don't know if that's an exception or they only have one ARIN PI customer. ~Seth
Re: IPv6 in the ARIN region
David Temkin wrote: I contacted 209 yesterday (due to the ongoing Cogent/174 silliness) and it seems like they are willing to turn up customer-facing v6, but have made it a sales process (versus a technical request) and so that complicates things. -Dave On Tue, Oct 13, 2009 at 8:27 AM, Seth Mattinen se...@rollernet.us wrote: New thread: who will route the full IPv6 table? So far I'm seeing PI /48's out of 2620:0:/23 from: NTT, 2914 ATT, 7018 Sprint, 1239 and 6175 Hurricane, 6939 Level 3, 3356 Global Crossing, 3549 Qwest, 209 Did I miss anyone? Qwest only carries one route (out of 4 total) though, don't know if that's an exception or they only have one ARIN PI customer. ~Seth Qwest still considers this a beta service. They're routing our /32, but we're still preferring our other peerings. Not to point fingers, but Force10 is advertising a /64 that HE (and subsequently Qwest others) are accepting. I'd suspect they'll accept most anything. 2620:0:380::/48 x:x:x::x 1537 209 6939 18508 I 2620:0:380:2::/64 x:x:x::x 1537 209 6939 18508 393222 I -- Chris
Re: IPv6 in the ARIN region
OCCAID as well. -Jack Carrozzo On Tue, Oct 13, 2009 at 1:08 PM, Ryan Werber rwer...@epiknetworks.com wrote: You can add TiNet AS3257 to the list. Ryan Werber Sr. Network Engineer Epik Networks -Original Message- From: Seth Mattinen [mailto:se...@rollernet.us] Sent: Tuesday, October 13, 2009 11:28 AM To: nanog@nanog.org Subject: IPv6 in the ARIN region New thread: who will route the full IPv6 table? So far I'm seeing PI /48's out of 2620:0:/23 from: NTT, 2914 ATT, 7018 Sprint, 1239 and 6175 Hurricane, 6939 Level 3, 3356 Global Crossing, 3549 Qwest, 209 Did I miss anyone? Qwest only carries one route (out of 4 total) though, don't know if that's an exception or they only have one ARIN PI customer. ~Seth
Re: ISP customer assignments
On 2009-10-13, at 08:05, Scott Morris wrote: While I may agree that teaching classful routing is stupid, the addressing part lets people start getting the concept of binary. That's true of classless addressing, too. When students have problems with non-octet bit boundaries, that just means you start with mask lengths that are multiples of 8. While I'd love to think that people coming out of the school system have a grasp of simple mathematical skills, more and more I'm finding that's not the case.I wouldn't spend a LOT of time with it, and I certainly wouldn't LEAVE at classful addressing, but it's a foundational step. Why is the presumption faulty? You were suggesting that classful addressing is reasonable to teach because it's simpler. It's not simpler, and in a modern-day context it's just wrong. Joe
Re: IPv6 filtering (was Re: IPv6 internet broken, cogent/telia/hurricane not peering)
On Mon, Oct 12, 2009 at 2:44 PM, Seth Mattinen se...@rollernet.us wrote: Marco Hogewoning wrote: As this thread has drifted off topic any way, would it for instance be a good idea to simply not accept mail from hosts that clearly use autoconfig ie reject all smtp from EUI-64 addresses. Of course not a wise idea for your own outbound relays which should handle mail from your customers but on the incoming side it might as well save a lot of headache and there is no need to keep track of which /64 are access networks. That would be really, really bad. My 3750's won't accept arbitrary /128's in an ACL unless it's EUI-64 or I make up something similar that it will like. I'm sure I'm not the only person who owns a 3750. As such, my mail servers are using EUI-64 addresses. ~Seth As I understand it, (and Cisco's documentation seems to support this, http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2ZY/command/reference/M1.html#wpxref54198 as an example), if you put a /128 in an ACL, you cannot specify any L4 port information for the address due to the limited width of the TCAM; in order to specify L4 information for the ACL, Cisco stuffs it into bits 24 through 39, losing what information was originally stored in those bits. It just so happens those are the fixed FFFE bits in an EUI-64 address, so if you're using EUI-64, no real information is lost. You can do your own non-EUI-64 addressing and still use ACLs with layer 4 port information as long as you don't put any addressing information into bits 24 through 39. Or, if you want to be *really* clever, you can address blocks of hosts with identical functions and identical security rules by assigning them addresses that differ *only* in bits 24 through 39; then, a single L4 /128 rule in you v6 ACL will actually apply to the entire equivalence class of servers, since from the router's perspective, it doesn't distinguish one server from the next as far as applying the ACL rule. However, if you opt to do this, make sure you document it *really* carefully, so the poor engineer who has to pick up after you will understand why the router is treating all of the servers identically, in spite of having what looks to be a single /128 listed in its ACL. ^_^; Matt
Re: ISP customer assignments
On Mon, Oct 12, 2009 at 8:32 PM, Scott Morris s...@emanon.com wrote: How many addresses do you like on point-to-point circuits? Scott I allocate a /64, but currently I configure only a /127 subnet on the actual interface. That prevents the neighbor table explosion/NS/ND traffic flooding challenges that can occur otherwise if you configure the link as a /64, and some not-nice person decides to start ping sweeping or nmapping the subnet; your router has to send out NS messages for every address in the /64 being probed, update the neighbor table with the incomplete entry, then flush it out when no ND message is seen. On a point-to-point link between routers you're never going to run stateless autoconfiguration, so there's not much downside to configuring it as a /127. Still...just in case, I do allocate the whole /64 for the link, so that if in the future it turns out that for some reason it really, *really* does have to be a /64 configured on it, I can make the change just by adjusting masks on each end, rather than having to actually renumber the entire network. *shrug* As always, your mileage will vary, but this has worked out well for me so far. Matt
Re: ISP customer assignments
How many addresses do you like on point-to-point circuits? That will become one of those great interview questions, because anyone who says something like a /127 or a /64 will be someone that you probably don't want to hire. The right answer is to explain that there are some issues surrounding the choice of addressing on point-to-point circuits and there has even been an RFC published discussing these issues, RFC 3627 http://www.ietf.org/rfc/rfc3627.txt The right decision for one network, or for one point in the topology, might not be the right decision for some other place. Some people may learn this by rote as a rule to always use a /126 or a /112 for point-to-point links, but even then it is best to understand why. --Michael Dillon
Re: IPv6 filtering (was Re: IPv6 internet broken, cogent/telia/hurricane not peering)
Matthew Petach wrote: As I understand it, (and Cisco's documentation seems to support this, http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2ZY/command/reference/M1.html#wpxref54198 as an example), if you put a /128 in an ACL, you cannot specify any L4 port information for the address due to the limited width of the TCAM; in order to specify L4 information for the ACL, Cisco stuffs it into bits 24 through 39, losing what information was originally stored in those bits. It just so happens those are the fixed FFFE bits in an EUI-64 address, so if you're using EUI-64, no real information is lost. You can do your own non-EUI-64 addressing and still use ACLs with layer 4 port information as long as you don't put any addressing information into bits 24 through 39. Interesting; makes sense though. Thanks for the explanation. ~Seth
Re: ISP customer assignments
I'm ok with teaching it to beginners to explain where we came from but that should be it. But why does that have to be done first? Why can't they teach current best practice in addressing, and then point out that historically it was done different but that caused problems which led to today's system? That said I still occasionally refer to networks in classful terms and I can think of several network engineers who have years of enterprise experience that still don't understand CIDR. I'm very careful about classful terminology because I work with a team of engineers who still occasionally must deal with a customer network (using very old gear) which requires class C addressing. For those who don't know what a Class C address is, it is an IP address in the range 192.0.0.0 to 223.255.255.255, i.e. it begins with binary 110, and the network prefix is fixed at /24. This means that 10.2.3/24 is not a class C address, and 192.2/16 is not a legal address block. --Michael Dillon
Re: ISP customer assignments
On 2009-10-13, at 14:46, Matthew Petach wrote: I allocate a /64, but currently I configure only a /127 subnet on the actual interface. For BRAS/PPPoE deployments you're dealing with a point-to-point link, so in principle you can number the endpoints using whatever you want. They're just host addresses and interface routes when it comes down to it. There's no need to number both ends within a single conventional subnet. In the test deployment I did earlier in the year I defined a pool of link addresses per BRAS (one /64 prefix per BRAS) and handed out one to each subscriber using ND/RA after IPv6CP had completed. To the subscriber that looked like a /128 host route, with some other arbitrary address on the far side. (We could have done it with RADIUS too, but having a static link address didn't seem particularly important.) A sub-side static /48 was then assigned via RADIUS and a route installed on the BRAS side, with DHCPv6 PD available as an option for clients who want auto-configuration rather than static config. It seemed to work. BRAS was a Juniper E-series (test box was an ERX310). Joe
Re: ISP customer assignments
On Oct 13, 2009, at 9:56 PM, Joe Abley wrote: On 2009-10-13, at 14:46, Matthew Petach wrote: I allocate a /64, but currently I configure only a /127 subnet on the actual interface. For BRAS/PPPoE deployments you're dealing with a point-to-point link, so in principle you can number the endpoints using whatever you want. They're just host addresses and interface routes when it comes down to it. There's no need to number both ends within a single conventional subnet. In the test deployment I did earlier in the year I defined a pool of link addresses per BRAS (one /64 prefix per BRAS) and handed out one to each subscriber using ND/RA after IPv6CP had completed. To the subscriber that looked like a /128 host route, with some other arbitrary address on the far side. (We could have done it with RADIUS too, but having a static link address didn't seem particularly important.) A sub-side static /48 was then assigned via RADIUS and a route installed on the BRAS side, with DHCPv6 PD available as an option for clients who want auto-configuration rather than static config. It seemed to work. BRAS was a Juniper E-series (test box was an ERX310). We run roughly the same, although we skip the whole globalscope address on the PPP, running localscope only works for the CPE we tested so far. MarcoH
DreamHost admin contacts
Any chance there's someone from DreamHost on NANOG? Or that someone might have a way to reach them other than by filing a trouble ticket with them? POP has seemingly been down all day, with Webmail sporadic at best. Just migrated my company's e-mail over to them last week, and with this, of course our company president has been putting a severe squeeze on me to fix it. Barring that, what recommendations might the NANOG community have for an extremely rock-solid e-mail hosting company? I realize that may mean self-promotion, but hey, bring it on. Much appreciated! -Andy
Re: ISP customer assignments
Dan White wrote: I don't recall if Pannaway is a layer 3 or layer 2 DSLAM, but we have a mix of Calix C7 (ATM) and Calix E5 (Ethernet) gear in our network. We're kinda in the same boat, but we expect to be able to gracefully transition to dual stacked IPv4/IPv6 without having to replace DSL modems, by reconfiguring the modems into bridged mode and leaving the layer 3 up to the customer's router. We're also in the process of budgeting for a new broadband aggregation router next year that will handle IPv6. Ask Pannaway if they can bridge traffic (either ATM PVC, or Ethernet QinQ/VLAN per subscriber) up to a broadband aggregator, like a Redback or Cisco. In Pannaway's case they want to pretend to be in the router business and we ended up buying their BARs. Their DSLAMs (BASs) are aggregated into their BARs and the BAR ring terminates on my Cisco core. I would love to eliminate the BARs from the equation but that's not an option. I've been by several (dozen) people that their Minnesota Pannaway office stopped selling the BARs and instead worked with Cisco for aggregation. I've also been told by Cisco folks that numerous sites are trying to get Cisco to take the Pannaway BARs in on trade-in. It would appear that no one like the BARs. Occam did it right. They didn't try to pretend to be in the router business. They stuck with L2. We're also in a bit of a pickle because we're using smart DSL modems/routers. I've argued for years for dumb DSL modems that had no routing/NAT capabilities at all. Unfortunately I didn't win that argument. Now we have what amount to CPEs that do not support IPv6. Whether they'll even pass IPv6 packets in a bridging mode is yet to be determined. Since some of the modems are Pannaway and given my experience with Pannaway and trying to bridge things over it without Pannaway messing with it in the middle (VLAN carrying IS-IS for example), I fully expect problems... It's no secret; I do not recommend Pannaway products based on my firsthand experience. Their SE actually told us 2 years ago that IPv6 was a fad and would never be adopted. Justin
Re: DreamHost admin contacts
Have had great luck (no outages) with Rackspace Mail (formerly Mailtrust). Quite affordable as well. Disclaimer: no affiliation, just a satisfied customer On 10/13/09, Andy Ringsmuth andyr...@inebraska.com wrote: Any chance there's someone from DreamHost on NANOG? Or that someone might have a way to reach them other than by filing a trouble ticket with them? POP has seemingly been down all day, with Webmail sporadic at best. Just migrated my company's e-mail over to them last week, and with this, of course our company president has been putting a severe squeeze on me to fix it. Barring that, what recommendations might the NANOG community have for an extremely rock-solid e-mail hosting company? I realize that may mean self-promotion, but hey, bring it on. Much appreciated! -Andy -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141
RE: DreamHost admin contacts
Barring that, what recommendations might the NANOG community have for an extremely rock-solid e-mail hosting company? I realize that may mean self-promotion, but hey, bring it on. Some people, when they say email hosting company, inherently mean hosting specifically of Microsoft Exchange email, contacts, and calendar. If that's what you're after, then I would recommend my employer's chosen hosted Exchange partner, Intermedia http://www.intermedia.net. They maintain server farms of Exchange clusters, and they have a very good customer portal (both at the administrator-of-the-site level and the individual end user). They also have an FTP-up-a-PST-file-and-merge-it-into-a-mailbox function that makes the initial migration from some other Exchange repository faster and more parallelizable than without it. We are extremely pleased, and we have basically stopped hosting Exchange for our own customers on our own in-house hardware, just using Intermedia as a branded service. Depending on your requirements (audit copy of every single email and and out, mandatory retention periods, BlackBerry connectivity, etc.), they probably can do anything you're asking for. Their uptime has been stellar except for one morning of about 3 to 4 hours, when a major MAN cable was busted around Manhattan somewhere and disconnected their datacenter. Other than that, we have not had the long, painful, tension-filled, customer-angering outage periods that we used to have with another provider which shall not be named. (OK, it will: GroupSpark. Stay far away from them.) -- Jeff Saxe Network Engineer, Blue Ridge InternetWorks Charlottesville, VA www.briworks.com
Re: DreamHost admin contacts
+1 for intermeida. I'm digging it. Though I've yet to find a way to turn off copying the originator of the e-mail when hitting reply all. Anyone know how to fix that? On 10/13/09 1:48 PM, Jeff Saxe wrote: Barring that, what recommendations might the NANOG community have for an extremely rock-solid e-mail hosting company? I realize that may mean self-promotion, but hey, bring it on. Some people, when they say email hosting company, inherently mean hosting specifically of Microsoft Exchange email, contacts, and calendar. If that's what you're after, then I would recommend my employer's chosen hosted Exchange partner, Intermediahttp://www.intermedia.net. They maintain server farms of Exchange clusters, and they have a very good customer portal (both at the administrator-of-the-site level and the individual end user). They also have an FTP-up-a-PST-file-and-merge-it-into-a-mailbox function that makes the initial migration from some other Exchange repository faster and more parallelizable than without it. We are extremely pleased, and we have basically stopped hosting Exchange for our own customers on our own in-house hardware, just using Intermedia as a branded service.
Re: ISP customer assignments
On 13/10/09 15:32 -0500, Justin Shore wrote: one like the BARs. Occam did it right. They didn't try to pretend to be in the router business. They stuck with L2. Occam did it partially right. They're half-bridging only - not true layer 2 to an aggregator (which is not necessary in their scenario). The problem with the access vendor doing half-bridging is that they have to be very layer-3 smart, and Occam was not quite there for IPv6 last time I worked with them (about 6 months ago). It's no secret; I do not recommend Pannaway products based on my firsthand experience. Their SE actually told us 2 years ago that IPv6 was a fad and would never be adopted. I haven't really been happy with any DSL vendor's response to my questions about IPv6. We happened to choose Calix, which is not particularly IPv6 friendly, but were successful in getting commitments from them to support IPv6 pass through. I have little doubt that Pannaway could implement IPv6, they just need to get enough demand from customers to make it worth their while. -- Dan White
Re: ISP customer assignments
Dan White wrote: Occam did it partially right. They're half-bridging only - not true layer 2 to an aggregator (which is not necessary in their scenario). The problem with the access vendor doing half-bridging is that they have to be very layer-3 smart, and Occam was not quite there for IPv6 last time I worked with them (about 6 months ago). When we did a RFP with them they didn't support v6 yet but they also wouldn't get in the way of passing v6 over them (minus the DHCP snooping/learning features of course). That was 2 years ago. I haven't looked at them since but they said that they'd work on it. I haven't really been happy with any DSL vendor's response to my questions about IPv6. We happened to choose Calix, which is not particularly IPv6 friendly, but were successful in getting commitments from them to support IPv6 pass through. None of the FTTH vendors we vetted supported v6 but at least a few said that they'd work on it. Pannaway's response though was priceless. I have little doubt that Pannaway could implement IPv6, they just need to get enough demand from customers to make it worth their while. Pannaway was bought a while back by Enablence. Hopefully they will drive a bit more clue into the products. Hopefully that SE isn't there anymore or if he is hopefully he's not driving product development. His other 2 answers about QoS not being needed because our links were sustaining saturation (microbursts anyone?) and that we didn't need an IGP because our network wasn't big enough and that static routing would do (for just shy of 100 routing devices in 3 POPs) was the icing on the cake. Unfortunately the decision was made to eat the cake anyway. Justin
Re: DreamHost admin contacts
Andy Ringsmuth wrote: Barring that, what recommendations might the NANOG community have for an extremely rock-solid e-mail hosting company? I realize that may mean self-promotion, but hey, bring it on. I would strongly recommend against GoDaddy's hosted email. See my earlier post on 9/8 about their idiotic use of ancient SORBS data. Justin
Re: ISP customer assignments
So far, I have only dabbled with IPv6, but my reading of the RFCs is that VLSM for lengths beyond /64 is not required. Subsequently, to use anything longer is an enormous gamble in an enterprise environment. I envision upgrading code one day and finding that your /127 isn't supported any more and they forgot to mention it. I'll stick to /64, though it does seem a horrible waste of space. Someone else might have read the RFC differently though. Eric Clark
Re: DreamHost admin contacts
On 10/13/09 2:19 PM, Justin Shore wrote: Andy Ringsmuth wrote: Barring that, what recommendations might the NANOG community have for an extremely rock-solid e-mail hosting company? I realize that may mean self-promotion, but hey, bring it on. I would strongly recommend against GoDaddy's hosted email. See my earlier post on 9/8 about their idiotic use of ancient SORBS data. I would strongly recommend against GoDaddy's hosted anything. See everywhere for their idiotic everything. There fixed that for you :)
Re: DreamHost admin contacts
On Tue, 13 Oct 2009 14:24:35 -0700 Charles Wyble char...@thewybles.com wrote: On 10/13/09 2:19 PM, Justin Shore wrote: Andy Ringsmuth wrote: Barring that, what recommendations might the NANOG community have for an extremely rock-solid e-mail hosting company? I realize that may mean self-promotion, but hey, bring it on. I would strongly recommend against GoDaddy's hosted email. See my earlier post on 9/8 about their idiotic use of ancient SORBS data. I would strongly recommend against GoDaddy's hosted anything. See everywhere for their idiotic everything. s/hosted// There fixed that for you :) -- John
[NANOG-announce] A few notes on recent events and items of interest for NANOG 47
Folks, A few notes on recent events and items of interest: (i).The NANOG Steering Committee approved the 2009 Election Ballot. It will be posted on Sunday, October 18 by noon when the polls open. (ii). Charter amendments http://nanog.org/governance/elections/2009elections/2009charteramend.php (iii). SC Candidates http://nanog.org/governance/elections/2009elections/2009sc_candidates.php (iv). Current PC Candidates http://nanog.org/governance/elections/2009elections/2009pc_candidates.php (v).Important dates - Voting for the 2009/2010 NANOG SC opens: 1200 EDT 10-18-09 - Voting for the 2009/2010 NANOG SC closes: 0915 EDT 10-21-09 - PC Candidate Information posted/nominations close: 10-19-09 The NANOG 47 agenda has been posted, so please check that out. We have a great line-up of topics and presenters. We hope to see many more in Dearborn. For those who are considering a NANOG Sponsorship, we encourage you to contact market...@merit.edu. The community really appreciates the support and vendors do have a wonderful opportunity to showcase their products. Thanks, and see you all in Dearborn. Dave signature.asc Description: Digital signature ___ NANOG-announce mailing list nanog-annou...@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce
Re: ISP customer assignments
eric clark wrote: So far, I have only dabbled with IPv6, but my reading of the RFCs is that VLSM for lengths beyond /64 is not required. Subsequently, to use anything longer is an enormous gamble in an enterprise environment. I envision upgrading code one day and finding that your /127 isn't supported any more and they forgot to mention it. I'll stick to /64, though it does seem a horrible waste of space. Someone else might have read the RFC differently though. I'm sure there's an RFC somewhere talking about Classful addressing pre-CIDR. Perhaps we should stop using CIDR in IPv4. It might stop working one day. ;) Operational reality helps to refine RFCs. Many people are already using longer prefixes for infrastructure and other purposes, so it's unlikely to go away. The only real issue is that some old hardware may not support prefixes longer than /64 in hardware and so may drop to software routing. I don't know of any examples of this though. adam.
Re: ISP customer assignments
Once upon a time, Michael Dillon wavetos...@googlemail.com said: How many addresses do you like on point-to-point circuits? That will become one of those great interview questions, because anyone who says something like a /127 or a /64 will be someone that you probably don't want to hire. The right answer is to explain that there are some issues surrounding the choice of addressing on point-to-point circuits and there has even been an RFC published discussing these issues, RFC 3627 http://www.ietf.org/rfc/rfc3627.txt Still learning here, so please go easy... I read the above, and I see section 4 item 3 says: The author feels that if /64 cannot be used, /112, reserving the last 16 bits for node identifiers, has probably the least amount of drawbacks (also see section 3). I guess I'm missing something; what in section 3 is this referring to? I can understand /64 or /126 (or maybe /124 if you were going to delegate reverse DNS?), but why /112 and 16 bits for node identifiers on a point-to-point link? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: ISP customer assignments
On Oct 13, 2009, at 4:26 PM, Chris Adams wrote: Once upon a time, Michael Dillon wavetos...@googlemail.com said: How many addresses do you like on point-to-point circuits? That will become one of those great interview questions, because anyone who says something like a /127 or a /64 will be someone that you probably don't want to hire. The right answer is to explain that there are some issues surrounding the choice of addressing on point-to-point circuits and there has even been an RFC published discussing these issues, RFC 3627 http://www.ietf.org/rfc/rfc3627.txt Still learning here, so please go easy... I read the above, and I see section 4 item 3 says: The author feels that if /64 cannot be used, /112, reserving the last 16 bits for node identifiers, has probably the least amount of drawbacks (also see section 3). I guess I'm missing something; what in section 3 is this referring to? I can understand /64 or /126 (or maybe /124 if you were going to delegate reverse DNS?), but why /112 and 16 bits for node identifiers on a point-to-point link? I'm actually completely unclear why people would use anything but a / 126 in 90% or more of cases. For all intensive purposes a /126 translates to a /30 in IPv4. Do people assign /24's to their point to point links today with IPv4? What's the point of a /64 on a point to point link? I'm not clear why people would intentionally be so frivolous with their IP space simply for the sake of because I can.
Re: ISP customer assignments
Chris Adams wrote: I guess I'm missing something; what in section 3 is this referring to? I can understand /64 or /126 (or maybe /124 if you were going to delegate reverse DNS?), but why /112 and 16 bits for node identifiers on a point-to-point link? The only thing special about /112 is that it is on a : boundary so it makes for some nice numbering plans: Let's say you set aside 2001::0:1::/64 for /112's link 1: 2001::0:1::1:1 2001::0:1::1:2 link 2: 2001::0:1::2:1 2001::0:1::2:2 This :1, :2 arrangement seems to be common but for internal links you could make the last hextet be a unique id for the specific router. That could use more than a few bits in a large network. - Kevin
Re: ISP customer assignments
That was the point. :) Scott Matthew Petach wrote: On Mon, Oct 12, 2009 at 8:32 PM, Scott Morris s...@emanon.com mailto:s...@emanon.com wrote: How many addresses do you like on point-to-point circuits? Scott I allocate a /64, but currently I configure only a /127 subnet on the actual interface. That prevents the neighbor table explosion/NS/ND traffic flooding challenges that can occur otherwise if you configure the link as a /64, and some not-nice person decides to start ping sweeping or nmapping the subnet; your router has to send out NS messages for every address in the /64 being probed, update the neighbor table with the incomplete entry, then flush it out when no ND message is seen. On a point-to-point link between routers you're never going to run stateless autoconfiguration, so there's not much downside to configuring it as a /127. Still...just in case, I do allocate the whole /64 for the link, so that if in the future it turns out that for some reason it really, *really* does have to be a /64 configured on it, I can make the change just by adjusting masks on each end, rather than having to actually renumber the entire network. *shrug* As always, your mileage will vary, but this has worked out well for me so far. Matt
Re: ISP customer assignments
While entirely possible, I actually view it going the other way. RFC 3627 points out some nice issues as far as DAD and anycast operation is concerned, but what I'd see (just my random opinion as I haven't bothered to write an RFC) is that it would make entirely much more sense to come up with a structure to STOP the anycast performance on a link that is point-to-point. While there are 340 undecillion addresses, that doesn't mean we need to waste a /64 on a link that will possibly only have two addresses anyway. My two cents. Scott eric clark wrote: So far, I have only dabbled with IPv6, but my reading of the RFCs is that VLSM for lengths beyond /64 is not required. Subsequently, to use anything longer is an enormous gamble in an enterprise environment. I envision upgrading code one day and finding that your /127 isn't supported any more and they forgot to mention it. I'll stick to /64, though it does seem a horrible waste of space. Someone else might have read the RFC differently though. Eric Clark
Re: ISP customer assignments
In a message written on Tue, Oct 13, 2009 at 06:26:20PM -0500, Chris Adams wrote: The author feels that if /64 cannot be used, /112, reserving the last 16 bits for node identifiers, has probably the least amount of drawbacks (also see section 3). I guess I'm missing something; what in section 3 is this referring to? I can understand /64 or /126 (or maybe /124 if you were going to delegate reverse DNS?), but why /112 and 16 bits for node identifiers on a point-to-point link? We use /112's, and do so for two (and a half) reasons: 1) If you think of all possible network to network interconnects they include the simple case like a single router on both ends, but they also include cases like two routers on one or both ends, and optionally with VRRP/HSRP. Maximally it appears 6 IP's may be required (two routers both ends, plus vrrp on each, statics at the VRRP). So it makes sense to have a 8 or 16 block of IP's per link so you never have to renumber the link if you switch these configurations. 2) Colon's separate 16 bit chunks in IPv6. /112's allow ::1, ::2 to be your IP's. The half a reason, if you have a /64 dedicate to point to point links, and use /112's, you have 2^(112-64) possible links. That's 281 trillion point to point links. Given 1, and 2, and the numbers /127's, /126's, /125's don't make any sense when you can standardize on one size fits all, and never run out. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpoNZzF1ehvR.pgp Description: PGP signature
Re: ISP customer assignments
On Tue, Oct 13, 2009 at 6:34 PM, Cord MacLeod cordmacl...@gmail.com wrote: IPv4? What's the point of a /64 on a point to point link? I'm not clear IP Addressing uniformity and simplicity. Use of /127s for Point-to-Point links introduces addressing complexity that may be avoided in V6: the scarcity of IPs necessitated it in V4 .At least /112 lies on an even 16-bit boundary, and that makes it the longest prefix that is a very good choice, if you do need a non-standard mask. Unless you have only a /32 of V6 space and 1 billion P2Pt links you need (or similar scenario), there is no utility in practicing rampant prefix length expansion, for the purpose of conservation (there may be other reasons such as preventing autoconfig). For all intensive purposes a /126 translates to a /30 in IPv4. Do people assign /24's to their point to point links today with Not really; there's a massive difference of scale.Say there's a big vat that contains all gold in the universe, you get to bring home one bucket of gold flakes to allocate to your customers. In the V4 universe, well you got a /19.. You got a 60 kilogram bucket, and a /30 represents a 1 troy ounce scoop taken out of that bucket.. In the V6 universe, even if you got a measly /48: one /64 from that is a 1 troy ounce gold flake out of your 2000 kilogram bucket. Should you really be worried about cutting up that flake? In reality... if you're an ISP the worst you have is a /32, you can think of a /48 that way, you do have 65536 of those /48s, also known as a 133,588,416kg bucket, since your /32 has a maximum of 4 billion /64s. Normally when you have a P2P link, it will mean you connect an end site also: that end site gets a /48 (Per the justification that allows you as an ISP to get a /32, such a large allocation). After assigning 65536 /64s, or 256 /64s (if you give out /56s to end sites) which you already do for each _end site_ as standard address allocation practice in V6, what's another single /64, seriously? -- -J
Re: ISP customer assignments
Once upon a time, Leo Bicknell bickn...@ufp.org said: 2) Colon's separate 16 bit chunks in IPv6. /112's allow ::1, ::2 to be your IP's. Yeah, this is what I forgot about. Makes sense now. Another (quite possibly dumb :-) ) few questions come to mind about IPv6 assignment: I would expect you just assign static addresses to servers. Are there pros/cons to using /64 or something else there? If I'm statically assigning IP (and DNS, etc. servers) info, why would I not just configure the gateway there as well (especially if you just make all local router interfaces ::1)? What about web-hosting type servers? Right now, I've got a group of servers in a common IPv4 subnet (maybe a /26), with a /24 or two routed to each server for hosted sites. What is the IPv6 equivalent? I can see a /64 for the common subnet, but what to route for aliased IPs for web hosts? It is kind of academic right now, since our hosting control panel software doesn't handle IPv6, but I certainly won't be putting 2^64 sites on a single server. Use a /112 here again as well? Use a /64 per server because I can? What about anycast-type addresses (e.g. DNS servers)? I route a few server IPv4 /32s around in my network; do you assign a /128, a /64 (with only one address in use), a /112, or something else? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: ISP customer assignments
On Tue, 13 Oct 2009 09:33:03 -0400, Justin Shore jus...@justinshore.com wrote: He didn't really give much of a reason for the /127s yet. I think it's coming up in a later session. I think it basically boiled down to whether or not the customer would actually use anything bigger. I'll write back when we get into that discussion. It's the IPv6 equiv of an IPv4 /30 link network. Then a /64 or whatever can be aimed to that link address. This is exactly what Bellsouth does for business DSL: the link has a dynamic address and your netblock is then routed to it. (this is confusing and unworkable for a lot of cheap hardware.)
Re: ISP customer assignments
In a message written on Tue, Oct 13, 2009 at 08:14:40PM -0500, Chris Adams wrote: I would expect you just assign static addresses to servers. Are there pros/cons to using /64 or something else there? If I'm statically assigning IP (and DNS, etc. servers) info, why would I not just configure the gateway there as well (especially if you just make all local router interfaces ::1)? All of our servers are in binary coded hex. :) That is, if your IPv4 address is 10.12.3.187, your IPv6 address is A:B:C:D::187. The router is ::1, just as in IPv4, and servers have static routes. We still use /64's everywhere. You may want to use temporary (privacy) addresses outbound. You many want to allow a server to use EUI-64 to get an address while doing an install, or similar. What about anycast-type addresses (e.g. DNS servers)? I route a few server IPv4 /32s around in my network; do you assign a /128, a /64 (with only one address in use), a /112, or something else? /128's for loopbacks, anycast addreses, and similar here. Typically out of a loopback /64. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpZg7bmq3t4a.pgp Description: PGP signature
RE: ISP customer assignments
What about anycast-type addresses (e.g. DNS servers)? I route a few server IPv4 /32s around in my network; do you assign a /128, a /64 (with only one address in use), a /112, or something else? Yes, on any sort of multi-access segment you really should use /64s. A little less stringent on an all router segment perhaps, but even then I shoot for /64s on anything that is not a PtP link ... /TJ -Original Message- From: Chris Adams [mailto:cmad...@hiwaay.net] Sent: Tuesday, October 13, 2009 9:15 PM To: nanog@nanog.org Subject: Re: ISP customer assignments Once upon a time, Leo Bicknell bickn...@ufp.org said: 2) Colon's separate 16 bit chunks in IPv6. /112's allow ::1, ::2 to be your IP's. Yeah, this is what I forgot about. Makes sense now. Another (quite possibly dumb :-) ) few questions come to mind about IPv6 assignment: I would expect you just assign static addresses to servers. Are there pros/cons to using /64 or something else there? If I'm statically assigning IP (and DNS, etc. servers) info, why would I not just configure the gateway there as well (especially if you just make all local router interfaces ::1)? What about web-hosting type servers? Right now, I've got a group of servers in a common IPv4 subnet (maybe a /26), with a /24 or two routed to each server for hosted sites. What is the IPv6 equivalent? I can see a /64 for the common subnet, but what to route for aliased IPs for web hosts? It is kind of academic right now, since our hosting control panel software doesn't handle IPv6, but I certainly won't be putting 2^64 sites on a single server. Use a /112 here again as well? Use a /64 per server because I can? What about anycast-type addresses (e.g. DNS servers)? I route a few server IPv4 /32s around in my network; do you assign a /128, a /64 (with only one address in use), a /112, or something else?
Re: DreamHost admin contacts
On Tue, Oct 13, 2009 at 01:34:47PM -0700, Brandon Galbraith wrote: Have had great luck (no outages) with Rackspace Mail (formerly Mailtrust). Quite affordable as well. It's definitely luck that's kept you outage free -- my former employer outsourced all their customer e-mail services to Mailtrust, and had no end of problems with it. They're on my avoid with extreme prejudice list. - Matt
Re: ISP customer assignments
Once upon a time, Nathan Ward na...@daork.net said: On 14/10/2009, at 2:14 PM, Chris Adams wrote: What about web-hosting type servers? Right now, I've got a group of servers in a common IPv4 subnet (maybe a /26), with a /24 or two routed to each server for hosted sites. What is the IPv6 equivalent? I can see a /64 for the common subnet, but what to route for aliased IPs for web hosts? It is kind of academic right now, since our hosting control panel software doesn't handle IPv6, but I certainly won't be putting 2^64 sites on a single server. Use a /112 here again as well? Use a /64 per server because I can? Why route them to the servers? I would just put up a /64 for the web servers and bind addresses to your ethernet interface out of that /64 as they are used by each site. I guess you might want to route them to the servers to save ND entries or something on your router? In the past, we saw issues with thousands of ARP entries (it has been a while and I don't remember what issues now though). Moving a block from one server to another didn't require clearing an ARP cache (and triggering a couple of thousand new ARP requests). Also, it is an extra layer of misconfiguration-protection: if the IPs are routed, accidentally assigning the wrong IP on the wrong server didn't actually break any existing sites (and yes, that is a lesson from experience). Of course, with IPv4, you never assigned a large enough block to begin with that would anticipate all growth, so routing additional blocks was a lot easier than changing blocks, cleaner than secondary IPs multiplying like crazy, etc., etc. None of that would be an issue with a single /64. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: ISP customer assignments
On 14/10/2009, at 3:49 PM, Chris Adams wrote: Once upon a time, Nathan Ward na...@daork.net said: On 14/10/2009, at 2:14 PM, Chris Adams wrote: What about web-hosting type servers? Right now, I've got a group of servers in a common IPv4 subnet (maybe a /26), with a /24 or two routed to each server for hosted sites. What is the IPv6 equivalent? I can see a /64 for the common subnet, but what to route for aliased IPs for web hosts? It is kind of academic right now, since our hosting control panel software doesn't handle IPv6, but I certainly won't be putting 2^64 sites on a single server. Use a /112 here again as well? Use a /64 per server because I can? Why route them to the servers? I would just put up a /64 for the web servers and bind addresses to your ethernet interface out of that /64 as they are used by each site. I guess you might want to route them to the servers to save ND entries or something on your router? In the past, we saw issues with thousands of ARP entries (it has been a while and I don't remember what issues now though). Moving a block from one server to another didn't require clearing an ARP cache (and triggering a couple of thousand new ARP requests). Yeah I figured as much. Also, it is an extra layer of misconfiguration-protection: if the IPs are routed, accidentally assigning the wrong IP on the wrong server didn't actually break any existing sites (and yes, that is a lesson from experience). I guess. The advantage of doing it with a single /64 for all of them is that you can move individual sites to other servers without much drama. That might not be useful for everyone of course. -- Nathan Ward
blackholes.us RBL is defunct and wildcarded
This is somewhat of a stability issue as I'm seeing a lot of remote mailservers affected. The blackholes.us series of RBLs (geotargetted IP space by country) is no more, hasn't been for awhile. It has now been wildcarded and answers positive to all queries. http://www.circleid.com/posts/20091013_unwelcome_afterlife_for_a_long_dead_blacklist/ Sorry if this is known, I checked the archives and didn't see anything. -mark -- Mark Jeftovic mar...@easydns.com / Jabber: mar...@easysip.com Founder / President, easyDNS Technologies Inc. Company Website: http://www.easyDNS.com Better Living Through Private World Domination: http://PrivateWorld.com
Re: blackholes.us RBL is defunct and wildcarded
The blackholes.us series of RBLs (geotargetted IP space by country) is no more, hasn't been for awhile. It has now been wildcarded and answers positive to all queries. The problem is that the domain has been abandoned, the IP block where its nameservers live was returned to ARIN and reallocated, and the new owner would like to get rid of the traffic. We've told him that wildcarding will not make the traffic go away, and I expect that in the next few days the domain will be turned off or at least the name servers pointed at someplace harmless. R's, John
Is v6 as important as v4? Of course not [was: IPv6 internet broken, cogent/telia/hurricane not peering]
On Oct 12, 2009, at 5:23 PM, Randy Bush wrote: sure would be nice if there was a diagnosis before the lynching If this happened in v4, would customers care 'why' it happened? Obviously not. Why should v6 be any different? It either is or is not production ready. I'm interested in HE's view on that. many of us are interested in diagnosis. few in your lynch rope. I think you are stretching things to make a pithy post. More importantly, you are missing the point. For the v6 'Net to be used, customers - you know the people who pay for those router things and that fiber stuff and all our salaries and such - need to feel some comfort around it actually working. This did not help that comfort level. And I believe it is valid to ask about it. Diagnosis is good. Fortunately, anyone who cares knows exactly what happened on a technical level - HE has no v6 transit and does not peer with Telia; Telia had CW transit, then they didn't, now they do. Took less time to 'diagnose' than your one-liners took to write. Were you actually interested in diagnostics, you would have spent some time looking as opposed to trying to be pithy to 10K of your not-so-closest buddies. Unfortunately, and you damned well know this, we are not going to get a /real/ diagnosis out of a busted peering relationship. Especially when one party is an incumbent telco. HE typically - and properly - will not discuss such relationships (modulo Mike's Cogent post, which even he says is unusual). And Telia won't discuss squat, full stop. So why it happened is a mystery, and will be for, well, ever. Diagnosis ends. However, the question still stands about the stability, and therefor, utility of the v6 'Net. Is it still some bastard child, some beta test, some side project? Or is it ready to have _revenue_producing_ traffic put on it? When a network as solid and customer-oriented as HE can have a long outage to such a large network as Telia, I submit it is not. I know, everyone is shocked. But operationally speaking, this matters. We can either say but it was just v6, or we can think about how to not have this happen again. The former leads no where. Perhaps we should choose the latter instead of making pithy posts? If that is a lynch rope, I will not bother arguing with you. Pigs mud all that. But that doesn't make it wrong, or irrelevant. In summary, we have the standard Chicken Egg problem. No one cares about v6, so no one puts anything important on v6, so no one cares about v6. HE was trying harder to break that vicious cycle than anyone else, yet even they do not come close to supporting v6 as much as they support v4. Sad times for the future of the Internet if we all need to use v6 Real Soon Now. I asked for HE's view on that. Would you mind explaining why you don't want to hear it? -- TTFN, patrick P.S. Being a curmudgeon is useful from time to time. But only if you are, well, being useful.
Seeking old NANOG list mbox archives
Hi All. I run a web archive for network security mailing lists at
http://seclists.org and have decided to add NANOG. I find that this
list often delves into security issues, including botnets, malware,
DoS attacks, ways to contain them, etc. So I've added a page with the
monthly archives since 2003, excerpts of the latest posts, RSS feeds,
searching, etc:
http://seclists.org/nanog/
The problem is that I have only been a list member for 6 years, while
the NANOG list has a rich history going back to 1994 ('92 if you count
the NSFNET Regional-Techs list it was formed from). I'd love to make
that whole history available. If anyone has archives going back
further than mine, please let me know. Traditional Unix-style mbox
files are preferred, but I'll take whatever I can get and massage them
into mboxes.
Thanks,
Fyodor
Re: ISP customer assignments
Chris Adams wrote: I guess I'm missing something; what in section 3 is this referring to? I can understand /64 or /126 (or maybe /124 if you were going to delegate reverse DNS?), but why /112 and 16 bits for node identifiers on a point-to-point link? It falls on a 16 bit boundry and is therefore easy to read. some numbering concessions within a vast space exist for the convenience of the poor humans not the machines. I can pick out the host side of the address in a /64 no problem but for some reason I have a trouble finding subnet boundaries on a series of /93s.
