Re: [Nanog-futures] Fwd: ADMIN: Reminder on off-topic threads
On Tue, Apr 21, 2009 at 09:43:22PM -0700, Paul Ferguson wrote: But I have to say (again, apologies) that security issues on the Internet - -- and especially the lack of engagement from ISPs -- is a major, major problem that NANOG could be a major facilitator, instead of turning its back on the woeful state of security affairs. I strongly concur with this. In any event, I think security-related issues are much more on topic than ARIN IPv4 policy foo. I think I mildly disagree with this. The allocation of chunks of IPv4 space to dedicated abusers, and the hijacking of chunks of IPv4 space by abusers, are security-related issues. So if you mean ARIN IPv4 policy in the sense of what their policies and procedures are, then I agree with you; if you mean it in the sense of what the real-world consequences are, then I'm not so sure. ---Rsk ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] Fwd: ADMIN: Reminder on off-topic threads
On Wed, Apr 22, 2009 at 05:46:50AM -0400, Rich Kulawiec wrote: On Tue, Apr 21, 2009 at 09:43:22PM -0700, Paul Ferguson wrote: [snip] In any event, I think security-related issues are much more on topic than ARIN IPv4 policy foo. I think I mildly disagree with this. The allocation of chunks of IPv4 space to dedicated abusers, and the hijacking of chunks of IPv4 space by abusers, are security-related issues. So if you mean ARIN IPv4 policy in the sense of what their policies and procedures are, then I agree with you; if you mean it in the sense of what the real-world consequences are, then I'm not so sure. Same here. Our ongoing problem (if one would call it that) is being a successful, large-tent organization. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] Fwd: ADMIN: Reminder on off-topic threads
Paul Ferguson fergdawgs...@gmail.com writes: The issue where is the pragmatism fairness of the MLC. So throw your hat in the ring next time there is a call for volunteers for the MLC. -r ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] Fwd: ADMIN: Reminder on off-topic threads
On Tue, Apr 21, 2009 at 09:32:13PM -0700, Paul Ferguson wrote: [snip] I don't mind gentle reminders, but non-specific gestures cloud the issue and sometimes appear hypocritical. I could easily name a few other threads on NANOG currently that I believe are off-topic, so if the MLC is going to send gentle-reminders, could it please be a bit more fair specific in it's reminders? That is all I ask, because right now, it seems rather arbitrary. I know in the past there was definitely a great deal of effort to balance the private reminders with the public to avoid noise and interminable meta- conversations. My impression is we're still seeing that balancing effort, so I'm boggled by the comment. A public reminder about three elements of a couple threads which were heading off the beam seems sane rather than 'hypocritical' or 'arbitrary'. If you've a specific suggestion for what can be done, the please share it. I think the MLC has been doing a good job and would be more than open to specific, constructive critique. Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] Fwd: ADMIN: Reminder on off-topic threads
On Apr 22, 2009, at 3:31 AM, Joe Provo wrote: I think the MLC has been doing a good job I would like to say that I agree with this statement. I think the MLC is doing a better job than previously, and could improve the list even a bit more if they cracked down sooner on these threads. Thank you, and keep up the good work. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
IPv4 Anycast?
Hello NANOG, I noticed that more than 3K prefixes are with 2 Origin ASes. Are they the simplest cases of anycast? Or they are mainly due to misconfiguration? --- --Zhenkai
Re: IPv4 Anycast?
On 22/04/2009, at 6:53 PM, Zhenkai Zhu wrote: Hello NANOG, I noticed that more than 3K prefixes are with 2 Origin ASes. Are they the simplest cases of anycast? Or they are mainly due to misconfiguration? The third (and probably more likely) option is that the prefixes are advertised by two providers as the customer wants redundancy with their own IP space, but does not have a public ASN. Ie. the customer has a circuit and possibly a BGP feed to two different providers. -- Nathan Ward
Re: IPv4 Anycast?
On Tue, Apr 21, 2009 at 11:53:02PM -0700, Zhenkai Zhu wrote: Hello NANOG, I noticed that more than 3K prefixes are with 2 Origin ASes. Are they the simplest cases of anycast? Or they are mainly due to misconfiguration? --- --Zhenkai i honestly don't remember the requirement for single-origin AS in a prefix announcement. Not sure why anyone would think that multiple origin announcements are a misconfiguration. --bill
Re: IPv4 Anycast?
Ah, that's very possible. So I suppose the 90 prefixes with 3 origin ASes are due to the same reason.. Then there is basically no inter-As anycast besides the anycast prefix for DNS root, since I only noticed like 8 prefixes that are announced by more than 3 ASes.. --Zhenkai Nathan Ward wrote: On 22/04/2009, at 6:53 PM, Zhenkai Zhu wrote: Hello NANOG, I noticed that more than 3K prefixes are with 2 Origin ASes. Are they the simplest cases of anycast? Or they are mainly due to misconfiguration? The third (and probably more likely) option is that the prefixes are advertised by two providers as the customer wants redundancy with their own IP space, but does not have a public ASN. Ie. the customer has a circuit and possibly a BGP feed to two different providers. -- Nathan Ward
Re: IPv4 Anycast?
On Apr 22, 2009, at 12:12 AM, Zhenkai Zhu wrote: Ah, that's very possible. So I suppose the 90 prefixes with 3 origin ASes are due to the same reason.. Then there is basically no inter-As anycast besides the anycast prefix for DNS root, since I only noticed like 8 prefixes that are announced by more than 3 ASes.. There's lots of strangeness out there, for instance: http://www.ep.net/policy.html Bill lets anyone who has an IP assignment from an ep.net /24 announce that /24. The term 'anycast' has some vagueness at the edges. Kris
Re: IPv4 Anycast?
On 22/04/2009, at 7:12 PM, Zhenkai Zhu wrote: Ah, that's very possible. So I suppose the 90 prefixes with 3 origin ASes are due to the same reason.. Then there is basically no inter-As anycast besides the anycast prefix for DNS root, since I only noticed like 8 prefixes that are announced by more than 3 ASes.. I never said that was the only reason, I'm sure plenty of people are doing anycast with different originating ASes. For example, check the 192.88.99.0/24 prefix. -- Nathan Ward
Re: IPv4 Anycast?
Zhenkai Zhu wrote: Then there is basically no inter-As anycast besides the anycast prefix for DNS root, since I only noticed like 8 prefixes that are announced by more than 3 ASes.. I presume you are using route-views or some such to get a larger picture of the BGP geography? I believe that many anycasts utilize the same ASN for their anycasted address space. I would expect that a few of them have an ASN specifically for their anycasted space. Given that the networks are duplicates, there's no requirement that one part of the AS needs to receive routes from the other part of the AS. For management and such of the devices, I presume there are separate netblocks advertised with a different ASN (possibly even statically assigned by a hosting network). Jack
Re: Important New Requirement for IPv4 Requests
Ricky Beam wrote: On Tue, 21 Apr 2009 19:22:08 -0400, Ken A k...@pacific.net wrote: Also, monthly bandwidth monitoring/shaping/capping are more easily done using one ip per hosted domain... That's why the infrastructure is virtualized and you monitor at or behind the firewall(s) and/or load balancer(s) -- where it *is* one IP per customer. Sure, it's easier (and cheaper) to be lazy and waste address space than setup a proper hosting network. I wasn't trying to point towards the 'right way', only adding to the list of motivations that are out there, and being discussed here. As ipv4 gets less cheap, and less easy to obtain, these motivations cease. That's a good thing. Ken -- Ken Anderson Pacific Internet - http://www.pacific.net
Re: Important New Requirement for IPv4 Requests
On 21-Apr-2009, at 21:50, bmann...@vacation.karoshi.com wrote: On Tue, Apr 21, 2009 at 08:24:38PM -0400, Ricky Beam wrote: FTP? Who uses FTP these days? Certainly not consumers. Even Cisco pushes almost everything via a webserver. (they still have ftp servers, they just don't put much on them these days.) well, pretty much anyone who has large datasets to move around. that default 64k buffer in the openssl libs pretty much sucks rocks for large data flows. So you're saying FTP with no SSL is better than HTTP with no SSL? Joe
Re: Important New Requirement for IPv4 Requests
On Wed, Apr 22, 2009 at 10:17:38AM -0400, Joe Abley wrote: On 21-Apr-2009, at 21:50, bmann...@vacation.karoshi.com wrote: On Tue, Apr 21, 2009 at 08:24:38PM -0400, Ricky Beam wrote: FTP? Who uses FTP these days? Certainly not consumers. Even Cisco pushes almost everything via a webserver. (they still have ftp servers, they just don't put much on them these days.) well, pretty much anyone who has large datasets to move around. that default 64k buffer in the openssl libs pretty much sucks rocks for large data flows. So you're saying FTP with no SSL is better than HTTP with no SSL? Joe (see me LEAPING to conclusions) yes. (although I was actually thinking http w/ SSL vs FTP w/o SSL) a really good review of the options was presented at the DoE/JT meeting at UNL last summer. Basically, tuned FTP w/ large window support is still king for pushing large datasets around. --bill
Broadband Subscriber Management
Hello Nanog! i just would like to see how other operators are handling broadband/DSL subscribers in their BRAS. Currently, we are implementing PPPoE with AAA on our Redback SE's and Cisco boxes. As our subscriber base grows and grows, management of user logins, passwords, password resets, password changes are getting really huge. Some customers also complains about the method of logging in, asking for an easier way to do it or dump logins altogether. We're looking at DHCP/CLIPS for Redback but haven't really tested it since it requires a new license for it. For Cisco, we've been empty so far in looking for a solution wherein we still have accounting and rate-limiting on subscriber vc's. how are network operators in your areas do it? DHCP? if i do DHCP, will i still have the flexibility of sending a radius reply attribute so i could rate-limit the subscribers speed? or still offer speed on demand via radius/time-based upgrade of their rate-limits during off-peak hours? thank you for any insights that you may share. -Sherwin
Re: Important New Requirement for IPv4 Requests
On Wed, Apr 22, 2009 at 02:27:14PM +, bmann...@vacation.karoshi.com wrote: On Wed, Apr 22, 2009 at 10:17:38AM -0400, Joe Abley wrote: On 21-Apr-2009, at 21:50, bmann...@vacation.karoshi.com wrote: On Tue, Apr 21, 2009 at 08:24:38PM -0400, Ricky Beam wrote: FTP? Who uses FTP these days? Certainly not consumers. Even Cisco pushes almost everything via a webserver. (they still have ftp servers, they just don't put much on them these days.) well, pretty much anyone who has large datasets to move around. that default 64k buffer in the openssl libs pretty much sucks rocks for large data flows. So you're saying FTP with no SSL is better than HTTP with no SSL? Joe (see me LEAPING to conclusions) yes. (although I was actually thinking http w/ SSL vs FTP w/o SSL) a really good review of the options was presented at the DoE/JT meeting at UNL last summer. Basically, tuned FTP w/ large window support is still king for pushing large datasets around. --bill whiner Joe... here's the link: http://www.internet2.edu/presentations/jt2008jul/20080720-tierney.pdf --bill
DSL Subscriber management
Hello Nanog! i just would like to see how other operators are handling broadband/DSL subscribers in their BRAS. Currently, we are implementing PPPoE with AAA on our Redback SE's and Cisco boxes. As our subscriber base grows and grows, management of user logins, passwords, password resets, password changes are getting really huge. Some customers also complains about the method of logging in, asking for an easier way to do it or dump logins altogether. We're looking at DHCP/CLIPS for Redback but haven't really tested it since it requires a new license for it. For Cisco, we've been empty so far in looking for a solution wherein we still have accounting and rate-limiting on subscriber vc's. how are network operators in your areas do it? DHCP? if i do DHCP, will i still have the flexibility of sending a radius reply attribute so i could rate-limit the subscribers speed? or still offer speed on demand via radius/time-based upgrade of their rate-limits during off-peak hours? thank you for any insights that you may share. -sherwin
RE: IPv4 Anycast?
-Original Message- From: Jack Bates [mailto:jba...@brightok.net] Given that the networks are duplicates, there's no requirement that one part of the AS needs to receive routes from the other part of the AS. For management and such of the devices, I presume there are separate netblocks advertised with a different ASN (possibly even statically assigned by a hosting network). Or you could just allow as-loops... not saying it's a good thing, but it could be done ;) Stefan Fouant
Re: Important New Requirement for IPv4 Requests
On Wed, Apr 22, 2009 at 10:17:38AM -0400, Joe Abley wrote: On 21-Apr-2009, at 21:50, bmann...@vacation.karoshi.com wrote: On Tue, Apr 21, 2009 at 08:24:38PM -0400, Ricky Beam wrote: FTP? Who uses FTP these days? Certainly not consumers. Even Cisco pushes almost everything via a webserver. (they still have ftp servers, they just don't put much on them these days.) well, pretty much anyone who has large datasets to move around. that default 64k buffer in the openssl libs pretty much sucks rocks for large data flows. So you're saying FTP with no SSL is better than HTTP with no SSL? (see me LEAPING to conclusions) yes. (although I was actually thinking http w/ SSL vs FTP w/o SSL) a really good review of the options was presented at the DoE/JT meeting at UNL last summer. Basically, tuned FTP w/ large window support is still king for pushing large datasets around. Why not just put it all in an e-mail attachment. Geez. Everyone knows that's a great idea. While HTTP remains popular as a way to interact with humans, especially if you want to try to do redirects, acknowledge license agreements, etc., FTP is the file transfer protocol of choice for basic file transfer, and can be trivially automated, optimized, and is overall a good choice for file transfer. Does anyone know what FTP stands for, anyways? I've always wondered... ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: Important New Requirement for IPv4 Requests
On Wed, 2009-04-22 at 09:42 -0500, Joe Greco wrote: FTP is the file transfer protocol of choice for basic file transfer, [...] Does anyone know what FTP stands for, anyways? I've always wondered... File Transfer Protocol. I know - it's a tricky one that, don't feel bad :-) Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]
On 22 apr 2009, at 0:19, Owen DeLong wrote: B) Again, while it might be the IETF's job, shouldn't the group trusted with the management of the IP space at least have a public opinion about these solutions are designed. Ensuring that they are designed is such a way to guarantee maximum adoption of v6 and thus reducing the potential for depletion of v4 space. The IETF specifically does not accept organizational input and requires instead that individuals participate. So how is the RIR model where you become a member and then participate better? If ARIN or the other RIRs have compelling arguments the only reason those arguments are compelling is because of their merit, not because they're from a RIR. it means that even if ARIN could develop a public opinion (which would have to come from the ARIN community by some process which we don't really have as yet), this opinion wouldn't mean much in the IETF's eyes. Well, if you, ARIN, or anyone else has input that should be considered when writing with a better specification for an IPv6-IPv4 translator, please let us know. For the past year or so the IETF behave working group has been considering the issue, and looked at a whole bunch of scenarios: from a small IPv6 network to the public IPv4 internet, to private IPv4 addresses, from a small IPv4 network to the public IPv6 internet, to (not entirely) private IPv6 addresses. The IPv6-IPv4 case seems doable with a bunch of caveats (it's still NAT) and we (for some value of we) want to get it out fast, but the other way around looks much more difficult and will at the very least take longer. The softwire(s?) working group is looking at tunneling IPv4 over IPv6 towards a big carrier grade NAT so IPv4 hosts/applications can still work across an IPv6 access network with only one layer of NAT. In v6ops CPE requirements are being discussed so in the future, it should be possible to buy a $50 home router and hook it up to your broadband service or get a cable/DSL modem from your provider and the IPv6 will be routed without requiring backflips from the user. So there is a fair chance that we'll be in good shape for IPv6 deployment before we've used up the remaining 893 million IPv4 addresses.
Re: Important New Requirement for IPv4 Requests
On 22 Apr 2009, at 10:42, Joe Greco wrote: While HTTP remains popular as a way to interact with humans, especially if you want to try to do redirects, acknowledge license agreements, etc., FTP is the file transfer protocol of choice for basic file transfer, and can be trivially automated, optimized, and is overall a good choice for file transfer. Does anyone know what FTP stands for, anyways? I've always wondered... :-) I was mainly poking at the fact that Bill seemed to be comparing SSL- wrapped file transfer with non-SSL-wrapped file transfer, but I'm intrigued by the idea that FTP without SSL might be faster than HTTP without SSL, since in my mind outside the minimal amount of signalling involved they both amount to little more than a single TCP stream. Bill sent me a link to a paper. I will read it. However, I take some small issue with the assertion that FTP is easier to script than HTTP. The only way I have ever found it easy to script FTP (outside of writing dedicated expect scripts to drive clients, which really seems like cheating) is to use tools like curl, and I don't see why HTTP is more difficult than FTP as a protocol in that case. Perhaps I'm missing something. Joe
Re: Broadband Subscriber Management
I don't understand why DSL providers don't just administratively down the port the customer is hooked to rather than using PPPoE which costs bandwidth and has huge management overhead when you have to disconnect a customer. I made the same recommendation to the St. Maarten (Dutch) phone company several years ago. They weren't listening either. That way you can rate limit via ATM or by throttling the port administratively. Just a suggestion Sherwin Ang wrote: Hello Nanog! i just would like to see how other operators are handling broadband/DSL subscribers in their BRAS. Currently, we are implementing PPPoE with AAA on our Redback SE's and Cisco boxes. As our subscriber base grows and grows, management of user logins, passwords, password resets, password changes are getting really huge. Some customers also complains about the method of logging in, asking for an easier way to do it or dump logins altogether. We're looking at DHCP/CLIPS for Redback but haven't really tested it since it requires a new license for it. For Cisco, we've been empty so far in looking for a solution wherein we still have accounting and rate-limiting on subscriber vc's. how are network operators in your areas do it? DHCP? if i do DHCP, will i still have the flexibility of sending a radius reply attribute so i could rate-limit the subscribers speed? or still offer speed on demand via radius/time-based upgrade of their rate-limits during off-peak hours? thank you for any insights that you may share. -Sherwin
Re: Broadband Subscriber Management
On Wed April 22 2009 11:01, Curtis Maurand wrote: I don't understand why DSL providers don't just administratively down the port the customer is hooked to rather than using PPPoE which costs bandwidth and has huge management overhead when you have to disconnect a customer. I made the same recommendation to the St. Maarten (Dutch) phone company several years ago. They weren't listening either. That way you can rate limit via ATM or by throttling the port administratively. Most likely because most RADIUS systems can be tied fairly easily directly to the billing/payment system which enables and disables (adds/removes) the customer from radius for payment/non-payment and therefore does not require any technical support to turn on/off customers. -- Larry Smith lesm...@ecsis.net
RE: IXP
But I recollect that FORE ATM equipment using LAN Emulation (LANE) used a broadcast and unknown server (BUS) to establish a point-to-point ATM PVC for each broadcast and multicast receiver on a LAN segment. As well as being inherently unscalable (I think the BUS ran on an ASX1000 cpu), this scheme turned the single stream concept of multicast on its head, creating essentially a unicast stream for each multicast PVC client. -Original Message- From: Lamar Owen [mailto:lo...@pari.edu] Sent: Tuesday, April 21, 2009 1:21 PM To: nanog@nanog.org Subject: Re: IXP On Monday 20 April 2009 18:57:01 Niels Bakker wrote: Ethernet has no administrative boundaries that can be delineated. Spanning one broadcast domain across multiple operators is therefore a recipe for disaster. Isn't this the problem that NBMA networks like ATM were built for? Cheap, fast, secure. It is obvious which two Ethernet chose. And which two ATM chose. Although secondhand ATM gear is coming down in price ATM has its own issues, but the broadcast layer 2 problem isn't one of them. Seems to me Ethernet layer 2 stuff is just trying today to do what ATM gear did ten years ago. Faster, of course, but still much the same. But, again, too bad ATM was just too expensive, and too different, and Gigabit Ethernet just too easy (at the time).
Re: IPv4 Anycast?
Then there is basically no inter-As anycast besides the anycast prefix for DNS root, since I only noticed like 8 prefixes that are announced by more than 3 ASes.. ...but inter-domain anycast is often achieved by using a single origin AS, which is then transited through the 'provider' autonomous systems. In which case, you may be looking for the wrong thing. Rob
Re: Broadband Subscriber Management
Quite a bit of overhead. Good article here: http://blog.ioshints.info/2009/03/adsl-overhead.html Curtis Maurand wrote: I don't understand why DSL providers don't just administratively down the port the customer is hooked to rather than using PPPoE which costs bandwidth and has huge management overhead when you have to disconnect a customer. I made the same recommendation to the St. Maarten (Dutch) phone company several years ago. They weren't listening either. That way you can rate limit via ATM or by throttling the port administratively. Just a suggestion
Re: Broadband Subscriber Management
Not disagreeing with you, just that SNMP write access is generally something that admins keep either turned off or very, very tightly controlled. In that context, how many devices (dslams, redbacks, etc) would have to be touched via SNMP to turn off a customer (or customers) versus simply removing their entry from a central radius database. -- Larry Smith lesm...@ecsis.net On Wed April 22 2009 12:25, you wrote: As opposed to SNMP and a script that would shut the port down via SNMP when the customer is disabled? Larry Smith wrote: On Wed April 22 2009 11:01, Curtis Maurand wrote: I don't understand why DSL providers don't just administratively down the port the customer is hooked to rather than using PPPoE which costs bandwidth and has huge management overhead when you have to disconnect a customer. I made the same recommendation to the St. Maarten (Dutch) phone company several years ago. They weren't listening either. That way you can rate limit via ATM or by throttling the port administratively. Most likely because most RADIUS systems can be tied fairly easily directly to the billing/payment system which enables and disables (adds/removes) the customer from radius for payment/non-payment and therefore does not require any technical support to turn on/off customers.
Re: Broadband Subscriber Management
As opposed to SNMP and a script that would shut the port down via SNMP when the customer is disabled? Larry Smith wrote: On Wed April 22 2009 11:01, Curtis Maurand wrote: I don't understand why DSL providers don't just administratively down the port the customer is hooked to rather than using PPPoE which costs bandwidth and has huge management overhead when you have to disconnect a customer. I made the same recommendation to the St. Maarten (Dutch) phone company several years ago. They weren't listening either. That way you can rate limit via ATM or by throttling the port administratively. Most likely because most RADIUS systems can be tied fairly easily directly to the billing/payment system which enables and disables (adds/removes) the customer from radius for payment/non-payment and therefore does not require any technical support to turn on/off customers.
Re: IPv4 Anycast?
Rob Evans wrote: Then there is basically no inter-As anycast besides the anycast prefix for DNS root, since I only noticed like 8 prefixes that are announced by more than 3 ASes.. ...but inter-domain anycast is often achieved by using a single origin AS, which is then transited through the 'provider' autonomous systems. Hi Rob, Do you mean multihoming here? Zhenkai In which case, you may be looking for the wrong thing. Rob
Re: IPv4 Anycast?
Jack Bates wrote: Zhenkai Zhu wrote: Then there is basically no inter-As anycast besides the anycast prefix for DNS root, since I only noticed like 8 prefixes that are announced by more than 3 ASes.. I presume you are using route-views or some such to get a larger picture of the BGP geography? Yes. I believe that many anycasts utilize the same ASN for their anycasted address space. I would expect that a few of them have an ASN specifically for their anycasted space. Given that the networks are duplicates, there's no requirement that one part of the AS needs to receive routes from the other part of the AS. For management and such of the devices, I presume there are separate netblocks advertised with a different ASN (possibly even statically assigned by a hosting network). I just want to make sure if I understand correctly. You mean that the anycasted address space can be announced in different places yet with the same origin AS? Zhenkai Jack
Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]
Iljitsch van Beijnum wrote: In v6ops CPE requirements are being discussed so in the future, it should be possible to buy a $50 home router and hook it up to your broadband service or get a cable/DSL modem from your provider and the IPv6 will be routed without requiring backflips from the user. So there is a fair chance that we'll be in good shape for IPv6 deployment before we've used up the remaining 893 million IPv4 addresses. I think this annoys people more than anything. We're how many years into the development and deployment cycle of IPv6? What development cycle is expected out of these CPE devices after a spec is FINALLY published? If the IETF is talking future and developers are also talking future, us little guys that design, build, and maintain the networks can't really do much. I so hope that vendors get sick of it and just make up their own proprietary methods of doing things. Let the IETF catch up later on. /RANT Jack
Re: IPv4 Anycast?
Zhenkai Zhu wrote: I just want to make sure if I understand correctly. You mean that the anycasted address space can be announced in different places yet with the same origin AS? Yes, and it is commonly done. Jack
L.A Area network Issues the past few days?
Has anyone seen any network issues the past few days? Yesterday we had some content delivery issues in the l.a area. Not getting any sort of response from our CDN, Limelight. Thanks in advance -- Prediction is very difficult, especially about the future. Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344
Re: L.A Area network Issues the past few days?
I can't speak to specific upper level issues but I can confirm that there was a slightly insane piece of network equipment yesterday AM. We sat it down and had a good conversation about manners and behavior in public and it shaped up. -Wayne On Wed, Apr 22, 2009 at 01:52:35PM -0700, Ray Sanders wrote: Has anyone seen any network issues the past few days? Yesterday we had some content delivery issues in the l.a area. Not getting any sort of response from our CDN, Limelight. Thanks in advance -- Prediction is very difficult, especially about the future. Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344 --- Wayne Bouchard w...@typo.org Network Dude http://www.typo.org/~web/
Re: L.A Area network Issues the past few days?
Could you elaborate on that a bit, please? off list is fine On Wed, 2009-04-22 at 14:07 -0700, Wayne E. Bouchard wrote: I can't speak to specific upper level issues but I can confirm that there was a slightly insane piece of network equipment yesterday AM. We sat it down and had a good conversation about manners and behavior in public and it shaped up. -Wayne On Wed, Apr 22, 2009 at 01:52:35PM -0700, Ray Sanders wrote: Has anyone seen any network issues the past few days? Yesterday we had some content delivery issues in the l.a area. Not getting any sort of response from our CDN, Limelight. Thanks in advance -- Prediction is very difficult, especially about the future. Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344 --- Wayne Bouchard w...@typo.org Network Dude http://www.typo.org/~web/ -- Prediction is very difficult, especially about the future. Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344
Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]
On 22 apr 2009, at 22:12, Jack Bates wrote: I think this annoys people more than anything. We're how many years into the development and deployment cycle of IPv6? What development cycle is expected out of these CPE devices after a spec is FINALLY published? That's certainly one way to look at this, and I'm just as unhappy about how long this has taken as you. On the other hand, it has been argued that these issues are outside the scope of the IETF in the first place, as it's just application of already established protocols, not developing something new. So another way to look at it is that at least the IETF is finally doing something because so far, nobody else has. What would have helped here is more push in this direction. If the IETF is talking future and developers are also talking future, us little guys that design, build, and maintain the networks can't really do much. I so hope that vendors get sick of it and just make up their own proprietary methods of doing things. Let the IETF catch up later on. People who run networks can do a lot: believe it or not, the IETF really wants input from network operators, especially in the early phases of protocol development when the requirements are established. Proprietary methods duking it out in the market place is nice for stuff that happens inside one box or at least within one administrative domain, but it would be a nightmare in broadband deployment where I want my Windows box to talk to my Apple wifi base station and my Motorola cable modem to the ISP's Cisco headend and their Extreme switches and Juniper routers.
Re: IPv4 Anycast?
Patrick W. Gilmore wrote: On Apr 22, 2009, at 4:35 PM, Jack Bates wrote: Zhenkai Zhu wrote: I just want to make sure if I understand correctly. You mean that the anycasted address space can be announced in different places yet with the same origin AS? Yes, and it is commonly done. I was under the impression anycast services with homogeneous origin AS was far more common than the heterogeneous. Almost all the instances I know of use homogeneous origin AS. I'd be interested in statistics either way. 192.88.99.0/24, 2002::/16, and 2001::/32 are some notable examples of heterogeneous origin AS. - Kevin
Re: IPv4 Anycast?
Kevin Loch wrote: Patrick W. Gilmore wrote: On Apr 22, 2009, at 4:35 PM, Jack Bates wrote: Zhenkai Zhu wrote: I just want to make sure if I understand correctly. You mean that the anycasted address space can be announced in different places yet with the same origin AS? Yes, and it is commonly done. I was under the impression anycast services with homogeneous origin AS was far more common than the heterogeneous. Almost all the instances I know of use homogeneous origin AS. I'd be interested in statistics either way. 192.88.99.0/24, 2002::/16, and 2001::/32 are some notable examples of heterogeneous origin AS. And those prefixes (6to4 Teredo) all come with annoying problems as one never knows which relay is really being used and it is hard to debug how the packets really flow. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: IPv4 Anycast?
Patrick W. Gilmore wrote: I was under the impression anycast services with homogeneous origin AS was far more common than the heterogeneous. Almost all the instances I know of use homogeneous origin AS. I'd be interested in statistics either way. The original question provides a good statistic, I think. Only 8 prefixes that were announced by more than 3 origin AS. Jack
Re: IPv4 Anycast?
On Apr 22, 2009, at 5:23 PM, Kevin Loch wrote: Patrick W. Gilmore wrote: On Apr 22, 2009, at 4:35 PM, Jack Bates wrote: Zhenkai Zhu wrote: I just want to make sure if I understand correctly. You mean that the anycasted address space can be announced in different places yet with the same origin AS? Yes, and it is commonly done. I was under the impression anycast services with homogeneous origin AS was far more common than the heterogeneous. Almost all the instances I know of use homogeneous origin AS. I'd be interested in statistics either way. 192.88.99.0/24, 2002::/16, and 2001::/32 are some notable examples of heterogeneous origin AS. I know examples of both, although I will admit I did not know any v6 ones. :) However, I'm just interested in global stats. -- TTFN, patrick
Re: IPv4 Anycast?
On Wed, Apr 22, 2009 at 04:13:38PM -0500, Jack Bates wrote: [snip] The original question provides a good statistic, I think. Only 8 prefixes that were announced by more than 3 origin AS. And the overall message is that only the (prefix holder|originating ASn[s]) can tell you if it is intended or not. Sadly, this is not a useful metric for a third-party to use to determine prefix annoucnement legitimacy. Perhaps an update to RPSL to allow for intentional multiple origins is overdue? [insert thread about folks who do/don't use tools regardless of appropriateness] -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]
Ron Bonica is leading a BOF during NANOG46 in Philly which may be of interest - BOF: IETF OPS MGMT Area, Ron Bonica, Juniper Networks Presentation Date: June 14, 2009, 2:00 PM - 3:30 PM Abstract: The IETF OPS MGMT Area documents management technologies and operational best common practices. The purpose of this BoF is to review activities in that area and solicit feedback to determine the usefulness of those activities to the operator community. We will also solicit proposals for new work that is of interest to users. The full agenda is up at - http://www.nanog.org/meetings/nanog46/agenda.php Cheers, -ren On Wed, Apr 22, 2009 at 5:18 PM, Iljitsch van Beijnum iljit...@muada.com wrote: On 22 apr 2009, at 22:12, Jack Bates wrote: I think this annoys people more than anything. We're how many years into the development and deployment cycle of IPv6? What development cycle is expected out of these CPE devices after a spec is FINALLY published? That's certainly one way to look at this, and I'm just as unhappy about how long this has taken as you. On the other hand, it has been argued that these issues are outside the scope of the IETF in the first place, as it's just application of already established protocols, not developing something new. So another way to look at it is that at least the IETF is finally doing something because so far, nobody else has. What would have helped here is more push in this direction. If the IETF is talking future and developers are also talking future, us little guys that design, build, and maintain the networks can't really do much. I so hope that vendors get sick of it and just make up their own proprietary methods of doing things. Let the IETF catch up later on. People who run networks can do a lot: believe it or not, the IETF really wants input from network operators, especially in the early phases of protocol development when the requirements are established. Proprietary methods duking it out in the market place is nice for stuff that happens inside one box or at least within one administrative domain, but it would be a nightmare in broadband deployment where I want my Windows box to talk to my Apple wifi base station and my Motorola cable modem to the ISP's Cisco headend and their Extreme switches and Juniper routers.
Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]
Iljitsch van Beijnum wrote: What would have helped here is more push in this direction. What really would help is more people who are not on NANOG pushing vendors to support IPv6. Even my Juniper SE has mentioned that I'm one of 2 people he's had seriously pushing for IPv6 features. Other vendors have just blown me off all together (we'll have it sometime). People who run networks can do a lot: believe it or not, the IETF really wants input from network operators, especially in the early phases of protocol development when the requirements are established. Serious input and participation means work and money. Too much for me. Doesn't help that when I was a wee one, mom dated someone who bragged about his status in the IETF and even had a pen. Sad way to be introduced to any organization, but I have seen similar mentalities regarding IETF mentioned here reinforcing my belief that arrogance is alive and I don't have the time and money to deal with it. Proprietary methods duking it out in the market place is nice for stuff that happens inside one box or at least within one administrative domain, but it would be a nightmare in broadband deployment where I want my Windows box to talk to my Apple wifi base station and my Motorola cable modem to the ISP's Cisco headend and their Extreme switches and Juniper routers. Sure, but the largest missing pieces for IPv6 are single box implementations. Proprietary NAT is single box. Will it break stuff? Probably, but when hasn't it? Corporate networks won't care. They'll deploy the vendor that supports it if that is what they want. BRAS/Aggregation is another single box solution but defines everything about an edge broadband network, supported by the access devices (switches, dslams, wireless ap/backhauls, etc). The layer 3 aware access devices all tend to have their own single box methods of security (DHCP snooping, broadcast scoping, etc, etc). I've seen quite a few systems that can't turn the security support off and break IPv6 because of it. Jack
Re: IPv4 Anycast?
On Apr 22, 2009, at 5:48 PM, Jack Bates wrote: Joe Provo wrote: And the overall message is that only the (prefix holder|originating ASn[s]) can tell you if it is intended or not. Sadly, this is not a useful metric for a third-party to use to determine prefix annoucnement legitimacy. Perhaps an update to RPSL to allow for intentional multiple origins is overdue? Legitimacy no, but it does lead one to believe that most anycast (given 3 locations) is homogeneous. I would love multiple origin support. There are tons which have 2 origin ASes. I realize that's not a lot of locations by today's anycast standards, but it is probably still common. OTOH: Serious anycast obviously requires more than 2, so I grant your point. The overwhelming majority of anycast is done from homogeneous origin AS. Which means I was right. :) -- TTFN, patrick
Bruce Perens: A Cyber-Attack on an American City
http://perens.com/works/articles/MorganHill/ Cyber-Attack on an American City Bruce Perens Just after midnight on Thursday, April 9, unidentified attackers climbed down four manholes serving the Northern California city of Morgan Hill and cut eight fiber cables in what appears to have been an organized attack on the electronic infrastructure of an American city. Its implications, though startling, have gone almost un-reported. That attack demonstrated a severe fault in American infrastructure: its centralization. The city of Morgan Hill and parts of three counties lost 911 service, cellular mobile telephone communications, land-line telephone, DSL internet and private networks, central station fire and burglar alarms, ATMs, credit card terminals, and monitoring of critical utilities. In addition, resources that should not have failed, like the local hospital's internal computer network, proved to be dependent on external resources, leaving the hospital with a paper system for the day. [...] Good read, good summary for less-technical people. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]
On 23/04/2009, at 8:12 AM, Jack Bates wrote: Iljitsch van Beijnum wrote: In v6ops CPE requirements are being discussed so in the future, it should be possible to buy a $50 home router and hook it up to your broadband service or get a cable/DSL modem from your provider and the IPv6 will be routed without requiring backflips from the user. So there is a fair chance that we'll be in good shape for IPv6 deployment before we've used up the remaining 893 million IPv4 addresses. I think this annoys people more than anything. We're how many years into the development and deployment cycle of IPv6? What development cycle is expected out of these CPE devices after a spec is FINALLY published? If the IETF is talking future and developers are also talking future, us little guys that design, build, and maintain the networks can't really do much. I so hope that vendors get sick of it and just make up their own proprietary methods of doing things. Let the IETF catch up later on. This work is actually mostly being done by some guys at Cisco, and other vendors have plenty of input as well. I would be surprised if CPEs that support the outcome of this work are far behind the RFC being published (or even a late draft). -- Nathan Ward
Re: Important New Requirement for IPv4 Requests
On 23/04/2009, at 3:33 AM, Joe Abley wrote: However, I take some small issue with the assertion that FTP is easier to script than HTTP. The only way I have ever found it easy to script FTP (outside of writing dedicated expect scripts to drive clients, which really seems like cheating) is to use tools like curl, and I don't see why HTTP is more difficult than FTP as a protocol in that case. Perhaps I'm missing something. It looks like curl can upload stuff (-d @file) but you have to have something on the server to accept it. FTP sounds easier. -- Nathan Ward
Two blocks of AS Numbers allocated
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, The IANA AS Numbers registry has been updated to reflect the allocation of two blocks of AS Numbers recently. 53248-54271Assigned by ARIN whois.arin.net 2009-04-21 54272-55295Assigned by ARIN whois.arin.net 2009-04-21 The registry can be found at: http://www.iana.org/assignments/as-numbers/as-numbers.xml Regards, Leo Vegoda Number Resources Manager, IANA -BEGIN PGP SIGNATURE- Version: 9.10.0.500 wj8DBQFJ78q5vBLymJnAzRwRAsxhAKCvxeFIPNw/gZnUDnH0Q51wWR7fiACeMKe+ XnUY36jXeaFRj2Ecn+4ZgFE= =cnqY -END PGP SIGNATURE-
Re: IXP
On Wed, Apr 22, 2009, Holmes,David A wrote: But I recollect that FORE ATM equipment using LAN Emulation (LANE) used a broadcast and unknown server (BUS) to establish a point-to-point ATM PVC for each broadcast and multicast receiver on a LAN segment. As well as being inherently unscalable (I think the BUS ran on an ASX1000 cpu), this scheme turned the single stream concept of multicast on its head, creating essentially a unicast stream for each multicast PVC client. IIRC, plenty of popular ethernet switches do this across their backplane for multicast .. Adrian
Re: IPv4 Anycast?
192.88.99.0/24, 2002::/16, and 2001::/32 are some notable examples of heterogeneous origin AS. And those prefixes (6to4 Teredo) all come with annoying problems as one never knows which relay is really being used and it is hard to debug how the packets really flow. I agree entirely. As a one of 6to4 relay operator (AS38646), I believe coordination among 6to4 and Teredo operators is needed. Does anyone know is there any operators group who are using 192.88.99.0/24, 2002::/16, and 2001::/32? --- No caffeine, No work. Shin SHIRAHATA s...@shirahata.name / t...@sfc.wide.ad.jp
IPv6 Operators List (which also covers 6to4 operation ;) (Was: IPv4 Anycast?)
Shin SHIRAHATA wrote: 192.88.99.0/24, 2002::/16, and 2001::/32 are some notable examples of heterogeneous origin AS. And those prefixes (6to4 Teredo) all come with annoying problems as one never knows which relay is really being used and it is hard to debug how the packets really flow. I agree entirely. As a one of 6to4 relay operator (AS38646), I believe coordination among 6to4 and Teredo operators is needed. Does anyone know is there any operators group who are using 192.88.99.0/24, 2002::/16, and 2001::/32? See http://lists.cluenet.de/pipermail/ipv6-ops/ Next to that: whois -h whois.ripe.net RFC3068-MNT that at at least should give you all the European 6to4 operators directly. Greets, Jeroen (RPSL is a nice thing isn't it ;) signature.asc Description: OpenPGP digital signature
Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]
Jack Bates wrote: Iljitsch van Beijnum wrote: In v6ops CPE requirements are being discussed so in the future, it should be possible to buy a $50 home router and hook it up to your broadband service or get a cable/DSL modem from your provider and the IPv6 will be routed without requiring backflips from the user. So there is a fair chance that we'll be in good shape for IPv6 deployment before we've used up the remaining 893 million IPv4 addresses. I think this annoys people more than anything. We're how many years into the development and deployment cycle of IPv6? What development cycle is expected out of these CPE devices after a spec is FINALLY published? ipv6 cpe devices have been / are being developed already. the doesn't mean there isn't more work to be done, in If the IETF is talking future and developers are also talking future, us little guys that design, build, and maintain the networks can't really do much. I so hope that vendors get sick of it and just make up their own proprietary methods of doing things. Let the IETF catch up later on. Generally the presumption is that people bring work that they are working on to the table. I work for an equipment vendor, if there's no reason for us to implement something why would would we expend cycles to work on it in the IETF either? /RANT Jack
