Re: Dual Homed BGP
On 1/23/20 6:01 PM, Brian wrote: Hello all. I am having a hard time trying to articulate why a Dual Home ISP should have full tables. My understanding has always been that full tables when dual homed allow much more control. Especially in helping to prevent Async routes. If you don't have full tables you will certainly have a default route somewhere, either set statically by you or advertised by your upstream. Accidents may happen: your ISP may blackhole a destination; sometimes they adjust loads, sometimes their redundancy is not properly set up or they may have an otherwise incorrect BGP configuration. Sometimes they just mess up. If you have full tables, you will simply stop getting the advertisements for the bad destinations from the bad ISP and your routers will take care of it because they will keep getting the advertisements from the other exit. If you don't have full tables and the mistake is in a destination for which the default route is used, your traffic will most probably be lost because they don't have enough information to know a different exit and you may get a call at midnight. It may or may not happened to me. ;-) Octavio.
Re: Email security: PGP/GPG & S/MIME vulnerability drop imminent
On 05/15/2018 04:34 AM, Rich Kulawiec wrote: > On Mon, May 14, 2018 at 01:47:50PM +0530, Suresh Ramasubramanian wrote: >> TL;DR = Don't use HTML email [snip] > > That's enough right there. HTML markup in email is used exclusively > by three kinds of people: (1) ignorant newbies who don't know any > better (2) ineducable morons who refuse to learn (3) spammers. > There are no exceptions. There is a need for rich-text these days. What is your proposal?
Re: Assigning /64 but using /127 (was Re: Waste will kill ipv6 too)
On 12/28/2017 11:39 AM, Owen DeLong wrote: > >> On Dec 28, 2017, at 09:23 , Octavio Alvarez <octalna...@alvarezp.org> wrote: >> >> On 12/20/2017 12:23 PM, Mike wrote: >>> On 12/17/2017 08:31 PM, Eric Kuhnke wrote: >>> Call this the 'shavings', in IPv4 for example, when you assign a P2P >>> link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, >>> due to ping-pong and just so many technical manuals and other advices, >>> you are told to "just use a /64' for your point to points. >> >> Isn't it a /127 nowadays, per RFC 6547 and RFC 6164? I guess the >> exception would be if a router does not support it. >> > Best practice used most places is to assign a /64 and put a /127 on the > interfaces. > Thanks for the info. Is this documented somewhere? Is there a disadvantage in letting many P2P links use different /127 networks within the same /64? Best regards, Octavio.
Re: Waste will kill ipv6 too
On 12/20/2017 12:23 PM, Mike wrote: > On 12/17/2017 08:31 PM, Eric Kuhnke wrote: > Call this the 'shavings', in IPv4 for example, when you assign a P2P > link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, > due to ping-pong and just so many technical manuals and other advices, > you are told to "just use a /64' for your point to points. Isn't it a /127 nowadays, per RFC 6547 and RFC 6164? I guess the exception would be if a router does not support it. Best regards, Octavio.
Re: Request for comment -- BCP38
On 09/26/2016 08:47 AM, Laszlo Hanyecz wrote: >> If you have links from both ISP A and ISP B and decide to send traffic >> out ISP A's link sourced from addresses ISP B allocated to you, ISP A >> *should* drop that traffic on the floor. There is no automated or >> scalable way for ISP A to distinguish this "legitimate" use from >> spoofing; unless you consider it scalable for ISP A to maintain >> thousands if not more "exception" ACLs to uRPF and BCP38 egress >> filters to cover all of the cases of customers X, Y, and Z sourcing >> traffic into ISP A's network using IPs allocated to them by other ISPs? >> > > This is a legitimate and interesting use case that is broken by BCP38. > The effectiveness of BCP38 at reducing abuse is dubious, but the > benefits of asymmetric routing are well understood. Why should everyone > have to go out of their way to break this.. it works fine if you just > don't mess with it. This is really wrong. Any ISP reserves the right to drop irrelevant traffic, traffic that does not belong to its network (read: dropping traffic that is not required to fulfill or is preventing the fulfillment of its contractual and technical requirements). BCP38 does not get in the way of the above and provides some potential benefits like avoiding blacklists in some cases, detecting attacks and hacked computers and contributing to the greater good of the community (yes, some ISPs choose to be good netizens as much as possible, and this is good). This means that applying BCP38 is just natural for those that wish to adopt it. Furthermore, being against it means being against the right to drop irrelevant traffic. In turn, this means that whenever a technical problem comes in conflict with BCP38, it is just a sign that there is some underlying technical flaw in the global Internet structure that should be addressed. I see this as a feature of BCP38. BCP38 does not break anything that it is not already broken, like the PD-addressing multihoming problem. The problem is not BCP38. Octavio.
Re: Use of unique local IPv6 addressing rfc4193
On 09/08/2016 04:09 PM, Pshem Kowalczyk wrote: > With NAT I have a single entry/exit point to those infrastructure subnets > which can be easily policed. I have used NAT in IPv4 scenarios as an alternative for lack of routing control in the return direction. However, this does not mean that this is the correct, best or orthodox way, even for IPv4, much less in IPv6. So, even though you can hack your way using NAT, this is really a routing problem, not an addressing problem. And you will just create problems for your users, your developers, yourself and third parties. > If I give them public IPs then they're routable and potentially can reach > the internet via devices that don't police the traffic. First: this can happen with NAT too. If other devices have access to the Internet, they can just NAT themselves even if the third-party exit has a private address. Second: private addresses can reach the Internet too. Many devices and ISPs don't block RFC5375-sourced packets from the Internet. So they can go out, although they can't come back. This is enough to create unsourceable attacks. In both cases NAT isn't really solving any of your problems fully. It's just a misconception. > My real question is does anyone bother with the fc00::/7 addressing or do > you use your public space (and police that)? I use public address space and I have made sure I have a single point of exit and return for my traffic. If I understood your concerns correctly, then I'd add that if the user forces traffic through third-party exit points, service is not guaranteed, as the third party may BCP38-filter it. If you want to absolutely prevent that, NAT will not help. You'll need other techniques. Best regards and good luck!
Re: NAT firewall for IPv6?
On 07/01/2016 07:28 PM, Edgar Carver wrote: > Is there some kind of NAT-based IPv6 firewall I can setup on the router > that can help block viruses? You need layer-7 firewalls for this. NAT-based "firewalls" (pseudo-firewalls, really) are layer-4 only. Those will not help you block typical viruses, as people will usually get infected from connecting to a compromised Website, or from an e-mail attachments. And even more, if connections are encrypted, an L7 firewall will not be able to do anything (whether IPv4 or v6) unless... better not open a can of worms. They will just help you block *some* attack vectors, though: those that rely on starting connections to your hosts from the outside. My guess is that, with regard to e-mail attachments and compromised Websites, IPv4 hosts are still attacked more than IPv6 ones, so, even if you turn off IPv6 you will still get attacked through IPv4. Everything else has been already said by others: fixing the Palo Alto is still your best bet. Good luck!
Re: rfc 1812 third party address on traceroute
On 05/31/2016 09:52 AM, Hugo Slabbert wrote:
>> I'm not sure if you mean that, if sent through C it should have the
>> source addres of A, or that it should actually be sent through A
>> regardless of the routing table (which sounds better to me).
>
> How is the latter better? What guarantees are there that the
> adjacent L3 device on R's interface A has a route for S [?]
Consider this scenario:
.---. ISP1ADDR/30{
D---|B R A|---[ ISP 1 ] {
`---C---' {
|(towards S) { S is someplace
| { over this side
.F---. {
---|G R2 H|--*[ ISP 2 ] {
`' ISP2ADDR/30{
In the asterisk there is BCP38 filtering which won't allow ISPADDR/30.
The packet expired on R incoming from ISP 1. Under Randy's scenario, the
TTL-exceeded packet would get dropped by ISP2.
The only way for the packet to get through is to follow RFC 1812, or to
send it back through A using A's address (this follows RFC 1812 4.3.2.4).
> and if such a route exists that it doesn't simply point at R?
If the route points back to R, then R just forwards it using the routing
table as with any packet.
Best regards.
Re: rfc 1812 third party address on traceroute
On 05/31/2016 11:22 AM, William Herrin wrote: >> I'm not sure if you mean that, if sent through C it should have the >> source addres of A, or that it should actually be sent through A >> regardless of the routing table (which sounds better to me). > > That doesn't make sense. There may be multiple next hops out A. If the > next hop in the FIB is out C, how would the router pick the next hop > to send to out A? Back to the physical address that sent the TTL-offending packet. > Anyway, Randy's comment was about source address selection, not > routing. With the packet coming from S into interface A, he'd prefer > that the ICMP error message be sourced from the IP address assigned to > A, not the IP address assigned to C or R. Thanks.
Re: rfc 1812 third party address on traceroute
On 05/30/2016 10:03 PM, Randy Bush wrote: > rfc1812 says > >4.3.2.4 ICMP Message Source Address > >Except where this document specifies otherwise, the IP source address >in an ICMP message originated by the router MUST be one of the IP >addresses associated with the physical interface over which the ICMP >message is transmitted. If the interface has no IP addresses >associated with it, the router's router-id (see Section [5.2.5]) is >used instead. > > some folk have interpreted this to mean that, if a router R has three > interfaces > >.-. >| | >| B |- D > S -| A R| >| C |- (toward S) >| | >`-' > > of course, simpletons such as i would desire the source of the time > exceeded message to be A. after all, this is the interface to which i > sent the icmp with the TTL to expire. Do you mean the source address or the source interface? I'm not sure if you mean that, if sent through C it should have the source addres of A, or that it should actually be sent through A regardless of the routing table (which sounds better to me). Octavio.
Re: Thank you, Comcast.
On 26/02/16 09:16, Brielle Bruns wrote: > Place the blame for local resolvers listening on WAN squarely where it > belongs - the router vendors who make these devices. As long as ISPs massively buy crappy hardware pieces, vendors will make them and sell them. That's how it works. Best regards.
Looking for docs on "A" RR duality of functions
Hi. Do you know if there are any docs (RFC, drafts, independent...) that study the tricks being done with the A/ RRs? What I mean is that it is currently being used not only to resolve the IP address of a hostname, but for load-balancing as well, the case being that the hostname is not just a "host"-name anymore, but a "service"-name (?) so to speak. I'd like to know if somebody else has gone deeper into this and if there are related documents on the matter. Thanks.
Re: Nat
On 15/12/15 10:08, Ahmed Munaf wrote: > Dear All, > > We are using cisco for natting, we'd like to change it to another brand like > A10 or Citrix. If you are willing to rephrase it to "we are using Cisco IOS for NATting, we'd like to change it to another platform or brand", you may want to take a look at Cisco ASAs. In my opinion those are better NATters than IOS. Best regards.
Re: AW: Uptick in spam
On 10/27/2015 05:09 AM, Ian Smith wrote: On Mon, Oct 26, 2015 at 9:40 PM, Octavio Alvarez <octalna...@alvarezp.org <mailto:octalna...@alvarezp.org>> wrote: On 26/10/15 11:38, Jürgen Jaritsch wrote: But it is originating all from different IP addresses. Who knows if this is an attack to get *@jdlabs.fr <http://jdlabs.fr/> blocked from NANOG and is just getting its goal accomplished. This is the part that's been bugging me. Doesn't the NANOG server implement SPF checking on inbound list mail? jdlabs.fr <http://jdlabs.fr> doesn't appear to have an SPF record published. It seems to me that these messages should have been dropped during the connection. That doesn't stop spam from hijacked accounts. For this case, an account was compromised, apparently. What if after 6 messages in the last 5 minutes with the same or absent 'In-Reply-To' moves the account to moderation mode. Easier said than implemented, though.
Re: Uptick in spam
On 27/10/15 05:40, Jutta Zalud wrote: >>> But it is originating all from different IP addresses. Who knows if this >>> is an attack to get *@jdlabs.fr blocked from NANOG and is just getting >>> its goal accomplished. >> >> This is the part that's been bugging me. Doesn't the NANOG server >> implement SPF checking on inbound list mail? jdlabs.fr doesn't appear to >> have an SPF record published. It seems to me that these messages should >> have been dropped during the connection. Well... an empty record is pretty much the same as "?all" anyway. The correct interpretation from the receiving MTA is "The SPF (if it exists) doesn't say if this is spam or not". This could, of course, vary from implementation to implementation. > If it does (which I don't know), it will probably check the SPF record > of the delivering mailserver, which was not *.jdlabs.fr as far as I can > see from the mailheaders. And also, most of the MX records end in ~all or ?all anyway, and ?all is the default if no "all" is defined, and the lack of jdlabs.fr SPF record is the equivalent of being defined as "?all". I now wonder if there is *really* a case for the ~ and ? operators in SPF and if we could deprecate ?all and ~all, and change the default to -all, by RFC. This would be just to make SPF useful. In its current state it asserts nothing, and --by its definition-- it forces no work from anybody. Best regards.
Re: AW: Uptick in spam
On 26/10/15 11:38, Jürgen Jaritsch wrote: > Hi, > > I added this two lines to our postfix header checks: > > /mike@sentex\.net/ DISCARD > /jdenoy@jdlabs\.fr/ DISCARD > > Worked very well: > > # grep -i discard /var/log/mail.log | grep -iE "@jdlabs|@sentex" | wc -l > 408 But it is originating all from different IP addresses. Who knows if this is an attack to get *@jdlabs.fr blocked from NANOG and is just getting its goal accomplished.
Fw: new message
Hey! New message, please read <http://iamakeupartistry.com/stop.php?b7rm2> Octavio Alvarez
Fw: new message
Hey! New message, please read <http://singdanceplaylearn.com/been.php?pw1m2> Octavio Alvarez
Fw: new message
Hey! New message, please read <http://piet.zijtveld.com/for.php?wrhgc> Octavio Alvarez
Re: Extraneous "legal" babble--and my reaction to it.
On 09/09/15 06:36, Dovid Bender wrote: > I am trying to understand why the legal babble bothers anyone. Does > it give you a nervous twitch? Remind you why you hate legal? It's > just text at the bottom of your email. I've seen it in multiple languages (not necessarily on this list). Furthermore, some mailing lists support HTML and when they send it in HTML it sends two copies. Some others even add a corporate image (sometimes mistakenly huge, sometimes small) to their signature. People do this a lot. If everybody did the same for all messages it would be a huge waste of bandwidth. For servers, because it's 1 byte times N subscriptions. For readers, because people should be able to read this in their mobile devices. For some this means access charges by byte. That's why it's frowned upon in mosts mailing lists and just directly forbidden in others. This is not new at all. Just my two cents. Best regards.
Re: Fwd: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with
On 06/07/15 19:12, Joe Greco wrote: Terrible idea. These are the kind of features that should be opt in, and Microsoft could have done that instead. It *is* an option. Opt-in and opt-out are two models of having an option. Also I meant being opt-out for the network administrator regarding the availability of the _optout suffix. Instead it should have been opt-in by the use of some _share suffix. Anyways, if you look on the first page of Customize settings, yes there's an option for Automatically connect to networks shared by my contacts and it CAN be turned off, but it defaults to on. That's an option for the users, not for the network administrator. As a network administrator (at home, at work, whatever) I have some trust for my users but not necessarily for the friends of my users. The decision should be up to the network administrator, not the user. The way it's implemented, user inaction makes him/her violate network usage policy. Best regards. Octavio.
Re: Fwd: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with your friends' friends
Terrible idea. These are the kind of features that should be opt in, and Microsoft could have done that instead. Does the 802.11 beacon support TLV data, like setting some opt-out flag without changing the SSID? (Even if the the flag name hasn't been yet agreed on?) Would this be a bad idea? Best regards. On 06/07/15 10:53, Jay Ashworth wrote: From Lauren, a new feature in Windows 10 I think this community probably wants to know about, to the extent you don't already. I *knew* I didn't like W10. :-) Cheers, -- jra - Forwarded Message - From: PRIVACY Forum mailing list priv...@vortex.com To: privacy-l...@vortex.com Sent: Wednesday, July 1, 2015 8:03:06 PM Subject: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with your friends' friends Windows 10 will share your Wi-Fi key with your friends' friends http://www.theregister.co.uk/2015/06/30/windows_10_wi_fi_sense/ In an attempt to address the security hole it has created, Microsoft offers a kludge of a workaround: you must add _optout to the SSID (the name of your network) to prevent it from working with Wi-Fi Sense. (So if you want to opt out of Google Maps and Wi-Fi Sense at the same time, you must change your SSID of, say, myhouse to myhouse_optout_nomap. Technology is great.) Microsoft enables Windows 10's Wi-Fi Sense by default, and access to password-protected networks are shared with contacts unless the user remembers to uncheck a box when they first connect. Choosing to switch it off may make it a lot less useful, but would make for a more secure IT environment. - - - --Lauren-- Lauren Weinstein (lau...@vortex.com): http://www.vortex.com/lauren Founder: - Network Neutrality Squad: http://www.nnsquad.org - PRIVACY Forum: http://www.vortex.com/privacy-info Co-Founder: People For Internet Responsibility: http://www.pfir.org/pfir-info Member: ACM Committee on Computers and Public Policy Lauren's Blog: http://lauren.vortex.com Google+: http://google.com/+LaurenWeinstein Twitter: http://twitter.com/laurenweinstein Tel: +1 (818) 225-2800 / Skype: vortex.com ___ privacy mailing list http://lists.vortex.com/mailman/listinfo/privacy
Re: gmail security is a joke
On 05/26/2015 08:44 AM, Owen DeLong wrote: I think opt-out of password recovery choices on a line-item basis is not a bad concept. For example, I’d want to opt out of recovery with account creation date. If anyone knows the date my gmail account was created, they most certainly aren’t me. OTOH, recovery by receiving a token at a previously registered alternate email address seems relatively secure to me and I wouldn’t want to opt out of that. (( many more snipped )) I would definitely opt-out from any kind of secret questions that I couldn't type by myself. Many many sites still think this is a good idea. Best regards.
Re: macomnet weird dns record
On 14/04/15 06:26, Colin Johnston wrote: Best practice says avoid such info in records as does not aid debug since mix of dec and hex Can you please cite the best practice document where this is stated? Thanks.
Re: BGP offloading (fixing legacy router BGP scalability issues)
On 04/03/2015 12:18 PM, Chris Boyd wrote: Can we please get back to the original topic? Also interested in the original topic. So far we have had one interesting and useful suggestion that I've seen -- Paul S. mentioned SIR https://github.com/dbarrosop/sir Have I missed any other solutions other than the prefix length filtering? Cisco BGP Selective Download was suggested on April 27th: http://seclists.org/nanog/2015/Apr/27 Best regards.
Re: Comcast thinks it ok to install public wifi in your house
On 10/12/14 18:41, Charles Mills wrote: In the US at least you have to authenticate with your Comcast credentials and not like a traditional open wifi where you can just make up an email and accept the terms of service. I also understand that it is a different IP than the subscriber. Based on this the subscriber should be protected from anyone doing anything illegal and causing the SWAT team to pay a visit. I haven't upgraded my gear though. Now..they are doing this on your electric bill and taking up space (albeit a small amount of it) in your home. Even if that weren't the problem, using third-party premises to host services without authorization is illegal (or should be). Also, using installed devices for purposes other than the receiving the service. Best regards.
Re: Tech Laptop with DB9
On 10/11/14 12:53, Darden, Patrick wrote: Get a cheap usb--serial converter. Check amazon for trend usb rs-232 db9 serial converter, tu-s9. Then you can just use whatever laptop. I've seen some cheap RS-232 converters fail with some devices. I was last bitten by one that just refused to work with Cisco Aironet APs 2600. I can't say if it was the device or the driver. I never knew what the problem ultimately was. Using a different model or brand worked. Just to have the precaution. O.
Re: large BCP38 compliance testing
On 05/10/14 18:44, Jimmy Hess wrote: On Thu, Oct 2, 2014 at 10:54 AM, valdis.kletni...@vt.edu wrote: The *real* problem isn't the testing. It's the assumption that you can actually *do* anything useful with this data. Name-n-shame probably won't get us far - and the way the US works, if there's a At least name and shame is something more useful than nothing done. Has it worked for the deaggregation offenders named by the CIDR report?
Re: The Next Big Thing: Named-Data Networking
On 05/09/14 07:16, Jay Ashworth wrote: How many Youtube subject tags will fit in *your* routers' TCAM? http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch-consortium-to-replace-tcpip [ Can someone convince me this isn't the biggest troll in the history of the internet? Cause it sounds like shoehorning DNS /and Google/ into IP in place of, y'know, IP addresses. ] Just my opinion: I just saw one video [1] so I may be misjudging or misunderstanding: When posted in 2007 there were many open problems yet. I hardly think that all the benefits would be real benefits and most things can be already done and it doesn't solve the most intricate problems of today's Internet. I wonder if it could really be fully trusted. Sounds nice and all, but I'm having trouble constructing it in my own head. What about live content (multicast), what about I as an end-user being able to certify my own information without relying on someone else? How to get the initial certificates, signed and trusted? When I request everybody near me to get some info and nobody have it, will everybody ask for everybody near each of them? And besides, most of the problems he describes can be solved by inserting a layer between 3 and 4 (something based on the Host Identity Protocol and its DNS records). It's still a change of paradigm but a smaller one: instead of connecting to hosts, connect to services that can be provided (dig -t ESRV) by many hosts each of which may have (dig -t ) many physical addresses. You set up a tunnel with internal signaling between end hosts that have multiple addresses and there you go: automatic path resiliency on both sides, automatic L3 mobility with connection persistency, some basic automatic encryption for all connections among those two hosts, all without requiring PI addressing (BGP would only be used for Internet providers and big sites)... It would scale and all that is needed is some changes in the OS, not applications, not the whole Internet. No need to justify equipment acquisition because it is end-to-end. The infrastructure doesn't need to be updated at first, but would need to catch up. Internet could be forced to catch up and if done properly, this gives automatic efficient addressing with a drastic reduction of the global routing table and automatic BCP38. IPv6 could be an excellent opportunity to get this working. [1] https://www.youtube.com/watch?v=gqGEMQveoqg Best regards.
Re: Multicast Internet Route table.
On 09/02/2014 05:46 AM, John Kristoff wrote: On Tue, 2 Sep 2014 04:47:37 + S, Somasundaram (Somasundaram) somasundara...@alcatel-lucent.com wrote: 1: Does all the ISP's provide Multicast Routing by default? No not all and even those that do often do not do so on the same gear, links and peers as their unicast forwarding. Why would that be, are network devices not able to support multicast? I have never used interdomain multicast but I imagine the global m-routing table would quickly become large.
Re: BGPMON Alert Questions
On 02/04/14 11:51, Joseph Jenkins wrote: So I setup BGPMON for my prefixes and got an alert about someone in Thailand announcing my prefix. Everything looks fine to me and I've checked a bunch of different Looking Glasses and everything announcing correctly. I am assuming I should be contacting the provider about their misconfiguration and announcing my prefixes and get them to fix it. Any other recommendations? Is there a way I can verify what they are announcing just to make sure they are still doing it? Here is the alert for reference: Your prefix: 8.37.93.0/24: Update time: 2014-04-02 18:26 (UTC) Detected by #peers: 2 Detected prefix: 8.37.93.0/24 Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network Provider,ID) Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of Thailand(CAT),TH) ASpath: 18356 9931 4651 4761 Same here. I got an alert for two prefixes. Same origin AS, same AS path for one of them: 18356 9931 4651 4761, but a different one for the other: 18356 38794 4651 4761.
Re: Hackers hijack 300, 000-plus wireless routers, make malicious changes | Ars Technica
On 03/04/2014 05:28 AM, jim deleskie wrote: Why want to swing such a big hammer. Even blocking those 2 IP's will isolate your users, and fill your support queue's. When the malicious DNS services get shutdown you will still have your support queue's filled, anyway. Doing it now will let you identify those affected. Blockage doesn't have to be all-or-nothing. It can be incremental, selective or all-or-nothing on some time windows. Better now than later.
Re: Hackers hijack 300, 000-plus wireless routers, make malicious changes | Ars Technica
On 04/03/14 10:33, Ian McDonald wrote: Until the average user's cpe is only permitted to use the resolvers one has provided as the provider (or otherwise decided are OK), this is going to be a game of whackamole. So long as there's an 'I have a clue' opt out, it appears to be the way forward to resolve this issue. Shutting down one set of 'bad resolvers' will simply cause a new set to be spawned, and a reinfection run round the still-unpatched cpe's of the world. Hi. That's a method for just temporarily managing the situation, not fixing it. If a techie opts-out, it doesn't mean other non tech-savvy users behind the same CPE won't go to a bad website and infect the vulnerable CPE. Once in this situation, it is *very* difficult The clueful user to find out. Most operators don't have an opt-out for SOHO services or it's a pain in the $BODYPART because of the dynamic nature of the SOHO services and the proper static identification of each user among the mass of not tech-savvy users. I've been through that as a user. The root of the problem is an unpatched CPE, that's right. The ISP is responsible for fixing that in pretty much all its own SOHO networks. It all boils down to finding the affected users and patching the CPEs. That has the additional benefit of involving the upstream CPE vendor. Best regards.
Re: 7206 VXR NPE-G1 throughput
On 02/10/2014 08:05 AM, Vlade Ristevski wrote: The ACL is a recent addition and we can probably do away with it. I didn't notice a significant increase in CPU or drops since adding it. But we usually peak at about 200Mbps on this link. The full routing table is a must since we're dual homed. You don't necessarily need the full routing table for dual home, only for outgoing load balance. You can have BGP, filter your routes away, just leave a default gateway and still have dual homing. Your outgoing traffic will work as if it were active-standby, though. My 0.02.
Re: 7206 VXR NPE-G1 throughput
On 02/10/2014 06:05 PM, Vlade Ristevski wrote: Are you suggesting getting the default gateway from both providers or getting the full table from one and using the default as a backup on the other (7206)? Whatever suits you best. Test and see. I'd just receive the full table anyway but filter them out, letting only the default routes go into the RIB. This should streamline your FIB. As I say, you lose outbound load balancing and your redundancy becomes all-or-nothing, but you save a few cycles. Again, I wouldn't recommend any of this because of the drawbacks, but along with other recommendations that others have made, like Turbo ACLs, it may buy you some time.
Re: Why won't providers source-filter attacks? Simple.
On 04/02/14 11:35, Jay Ashworth wrote: It *is in their commercial best interest (read: maximizing shareholder value) *NOT* to filter out DOS, DDOS, and spam traffic until their hand is forced -- it's actually their fiduciary duty not to. That's short-sighted, but I agree in that that's what happens. Not filtering doesn't prevent them to operate. *THIS* is the problem we have to fix. Source-based routing when going back to the backbone, at least on IPv6. It allows end-user multihoming with no BGP, and routers could be programmed to, by default, drop packages that don't know how to source-route, hence, automatically source filtering for those that don't care enough. Difficult to do. Will take years to develop and adopt... if at all.
Re: BCP38 is hard, was TWC (AS11351) blocking all NTP?
On 04/02/14 14:18, John Levine wrote: I was at a conference with people from some Very Large ISPs. They told me that many of their large customers absolutely will not let them do BCP38 filtering. (If you don't want our business, we can find someone else who does.) The usual problem is that they have PA space from two providers and for various reasons, not all of which are stupid, traffic with provider A's addresses sometimes goes out through provider B. Adding to the excitement, some of these customers are medium sized ISPs with multihomed customers of their own. I haven't read it all, but section 3 says: However, by restricting transit traffic which originates from a downstream network to known, and intentionally advertised, prefix(es), the problem of source address spoofing can be virtually eliminated in this attack scenario. If ISP has customer A with multiple *known* valid networks --doesn't matter if ISP allocated them to customer or not-- and ISP lets them all out, but filters everything else, ISP is still complying with BCP 38. Here it's not a matter of blocking just because. It's blocking unknown addresses. It doesn't either mean that ISP should not open the filters if a new prefix is requested by the customer.
Re: BCP38 is hard, was TWC (AS11351) blocking all NTP?
On 04/02/14 15:24, John R. Levine wrote: If ISP has customer A with multiple *known* valid networks --doesn't matter if ISP allocated them to customer or not-- and ISP lets them all out, but filters everything else, ISP is still complying with BCP 38. Of course. The question is how the ISP knows what the customer's address ranges are, without demanding vast amounts of nitpicky manual work on both sides. The same way BGP outbound prefix filters are applied nowadays, would be a good start. Some have BGP filtering but don't have ACLs.
Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
On 04/02/14 16:31, Livingood, Jason wrote: Can somebody explain to me why those who run eyeball networks are able to block outbound packets when the customer hasn't paid their bill, but can't seem to block packets that shouldn't be coming from that cablemodem? i suspect the non-payment case is solved at a layer below three In a DOCSIS network the source address verification (as Tony said) is typically done on the CMTS IIRC. Turning a customer off for non-payment is done in an accounts management / billing system. While I am sure continuing to agree with each other that spoofing is bad, we lack actionable data. ;-) As I said in another thread, I think someone / some group needs to invest to collect actual data and share the results openly. So any volunteers out there? I¹m sure there are lots of ways to underwrite independent research on the subject (contact me off-list). Maybe I'm oversimplifying things but I'm really curious to know why can't the nearest-to-end-user ACL-enabled router simply have an ACL to only allows packets from end-users that has a valid source-address from the network segment they provide service to. What I'm failing to understand, and again, please excuse me if I'm oversimplifying, is what data do you need from researchers, specifically. What specific actionable data would be helpful? Why does the lack of the data prevent you from applying an ACL.
Re: Do network diagnostic tools need upgrade?
On 02/03/2014 05:33 AM, Ammar Salih wrote: Hello NANOG list members, I have a question for you, are you happy with the current network diagnostic tools, like ping, trace route .. etc, What tools are you referring to by ...? There are many others. I like tcptraceroute (there are two variants of it) and mtr. don't you think it's time to have an upgraded version of icmp protocol? What is it that you are thinking? ICMP is for signaling between machines. Increasing signaling for human diagnostics can lead to reconnaissance attacks. We don't want yet another option for some to incorrectly block ICMP [1], which in turn leads to other problems. [1] ... when they want to just block ICMP echo and reply, which is also bad enough and must be done really selectively. First scenario: To be able to troubleshoot advanced networks with complex QoS and policy-based routing configuration, where ping, traceroute and other network diagnostic tools do not provide accurate readings, for example, you are troubleshooting a web server with ping, and it looks functioning quite well (packet loss and round trip time is all good), but web services are still significantly slow, the fact is icmp and tcp:80 might have different priorities and bandwidth limits on each router along the path between the client and the server, in this case, network admins usually use telnet applications like (Paping), well it may help if the forward and return path of all packets are exactly the same. tcptraceroute. Second scenario: So another possible scenario is that you need to determine readings for forward and return paths, TraceRoute for example gives you forward path only using icmp. But what if you need to troubleshoot a VoIP server for example, assuming that packets return path might not be the same as forward path. It depends. Asymmetric routing is not necessarily bad unless it causes a problem like packet loss, high latency, etc. For example, if the return path has packet loss but you should 'hopefully' (yeah I know...) notice it in the traceroute if you increment the probe count or run it twice. Or try mtr, a periodic traceroute with different statistics presentation that significantly reduces the 'hopefully' problem. Third scenario: One of the most common problems in networking, is that you don't have access to all equipment between client and server, but you have to troubleshoot the path between them and to understand where the problem exactly is in order to contact the right person without having the privilege to check the configuration on each router. This one's more difficult but also it depends. State a specific problem case. Fourth scenario: Also, with trace route you can't determine the actual path, for example, the router may direct http traffic to proxy server while leaving other traffic going through a different hop. tcptraceroute.
Re: Internet Society survey regarding Network Operator involvement with the IETF
On 02/02/2014 07:52 AM, John Curran wrote: NANOGers - The folks at the Internet Society are looking for input into how network operators are (or are not) involved in IETF standards development. To that end, they've put together a short survey for network operators on this topic and are asking for help in getting the message out about it. The survey is available here: https://internetsociety2.wufoo.com/forms/operators-and-the-ietf/ Some additional background info available here - http://www.circleid.com/posts/20140130_how_do_we_get_more_network_operator_feedback_into_ietf_standards/ If you feel so inclined, please complete the survey; it looks to be relatively short/painless. The survey has a problem: the 'Previous' link actually continues on or submits the form. I could not correct a response and the form went on incomplete. I browse without JavaScript so this may be related to the problem.
Re: Policy-based routing is evil? Discuss.
On 10/11/2013 10:27 AM, William Waites wrote: I'm having a discussion with a small network in a part of the world where bandwidth is scarce and multiple DSL lines are often used for upstream links. The topic is policy-based routing, which is being described as load balancing where end-user traffic is assigned to a line according to source address. I wouldn't say evil, I have found it really useful in some cases. You just need a different approach to the network design. I'd just say it's not the easiest way and yeah, I try to generally avoid it. - It's brittle, when a line fails, traffic doesn't re-route This depends on how flexible the PBR implementation on your router is. If your router can have conditionals like this: * match: source address A link P available -- send it to link P * match: source address A -- unconditionally send it to fallback link F Then your users will converge quite nicely. Also, make sure you prepare for router redundancy. Configuration can get pretty complex, though, and link addition can require redesign of the whole policy. - None of the usual debugging tools work properly No, but then, they can't expect usual debugging tools with unusual scenario. You may need to develop some new tools and teach them how to use them. - Adding a new user is complicated because it has to be done in (at least) two places With a good design this burden can be significantly lowered to the point of being not 100% but 80 or 90% effective, so to speak. Consider a good topology and a good addressing plan.
Re: iOS 7 update traffic
That's just the typical Bittorrent /client/, but the idea of using Bittorrent means the /protocol/. A special Bittorrent client could be written for ISPs with uploads disabled and Apple could also disable them on the update-downloading Bittorrent client for the phones. The clients (be it Bittorrent or not) would still download the MD5 hash after the download finishes to verify the integrity of the download, and Apple would still be able to measure the amount of downloaded images. For the ISP, this would mean minimal amount of effective downloads. On 09/23/2013 07:31 AM, Blake Dunlap wrote: Bit torrent is a way to lighten the load on the originator, and to increase the speed of the acquisition from the receivers. It is not a tool to decrease network load, if anything it does the opposite most of the time. Every now and then, a client will find a local network peer, but its usually an accident more than anything from the algorithm it uses to try to find the fastest senders with pieces it needs. This is most often a product of far end congestion and what pieces are completed, and rarely upstream related barring major issues. The algorithim is self greedy, not altruistic, and definitely not written with ISP load issues in mind. I'd much prefer CDN content over bittorrent from the ISP side.
Re: iOS 7 update traffic
On 09/23/2013 08:36 PM, Joe Greco wrote: That's just the typical Bittorrent /client/, but the idea of using Bittorrent means the /protocol/. A special Bittorrent client could be written for ISPs with uploads disabled and Apple could also disable them on the update-downloading Bittorrent client for the phones. The clients (be it Bittorrent or not) would still download the MD5 hash after the download finishes to verify the integrity of the download, and Apple would still be able to measure the amount of downloaded images. So then all the networks that have done $things to BitTorrent to demote it to second-rate traffic will suddenly have a bunch of very angry Apple fans whose downloads are mysteriously having issues. No, usually that traffic is demoted right before upstream (or in some way not very near to the provider-edge-to-customer device). Once the download is ready on the ISP, that would be a solved problem. And also, the phone could support two protocols as a transition. It's the easiest solution I've read so far. There are others but not as easy. And then - assuming you intend for more things than just Apple to go this route - all the CDN's would need to be redesigned to support BT too. Why can't it be implemented as an independent mean of delivering updates? It seems like it'd be simpler for Apple to figure out how to validate a partial download and then resume. It isn't like that would be cutting edge technology. I think I might even have seen it happen before. Validate partial download? How would that help to reduce the overall load on the ISP? That is only limited to reducing the redundant traffic, where redundant means twice per device, not twice per content, which is the real problem. Cheers.
Re: iOS 7 update traffic
Again, as others have said: complain to the ISP that most probably oversubscribed their links. On 19/09/13 15:29, Warren Bailey wrote: Your software updates (you meaning a user of the Internet) should not affect my experience. I'm not advocating we go back to 5.25 floppies and never look back. I'm asking.. Is there a way for a COMPUTER and PHONE manufacturer to distribute their software without destroying most last mile connectivity? Who else has had traffic surges like this? And who else has a Nanog strike team coming in screaming buy more bandwidth? ;)
Re: Google's QUIC
On Fri, 28 Jun 2013 19:31:35 -0700, Jim Popovitch jim...@gmail.com wrote: On Fri, Jun 28, 2013 at 10:12 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: I wish my Debian mirror would just be the mirror.debian.net *service* (not host), and the network could choose the best for me. Try http.debian.net see: http://http.debian.net Interesting! Didn't know of that. However, http.debian.net is still a host that redirects me every time. If 46.4.205.43 goes down, I have no way to connect anymore. -- Octavio. Twitter: @alvarezp2000 -- Identi.ca: @alvarezp
Re: Google's QUIC
On Fri, 28 Jun 2013 13:09:43 -0700, Michael Thomas m...@mtcc.com wrote: http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1 Sorry if this is a little more on the dev side, and less on the ops side but since it's Google, it will almost certainly affect the ops side eventually. My first reaction to this was why not SCTP, but apparently they think that middle boxen/firewalls make it problematic. That may be, but UDP based port filtering is probably not far behind on the flaky front. Sounds like a UDP replacement. If this is true, then OS-level support will be needed. If they are on this, then it's the perfect opportunity to fix some other problems with the Internet in general. My reaction is: why, oh why, repeat the same mistake of merging everything on the transport layer and let the benefits be protocol-specific instead of separating the transport from session. I mean, why not let redundancy and multipath stay on the transport layer through some kind of end-user transport (like the Host Identification Protocol, RFC 5201) and let a simpler TCP and UDP live on top of that, on the session layer. Streamline the protocols and separate their functionality. It's easier than it sounds. -- Octavio.
Re: Google's QUIC
On Fri, 28 Jun 2013 13:39:04 -0700, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, Jun 28, 2013 at 4:26 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: Sounds like a UDP replacement. If this is true, then OS-level support will be needed. If they are on this, then it's the perfect opportunity to fix some other problems with the Internet in general. I'm no genius, but doesn't the article say it's UDP? (in the name of the protocol even) I was trying to emphasize replacement, not UDP. This is, that works on the same layer, that requires OS-level modifications, as opposed to a protocol that could be similar to UDP but work on the application layer. My point was that all that work could be focused on a *really* good transport (even with end-user multihoming without bloating the routing table), and have streamlined TCP and UDP that takes advantage of the new protocol. Everyone's calling upon SCTP. Implementing similar techniques on multiple transport protocols calls for a transport-session separation. -- Octavio.
Re: Google's QUIC
On Fri, 28 Jun 2013 13:57:48 -0700, Christopher Morrow morrowc.li...@gmail.com wrote: again... not a super smart on this stuff, but.. why does it require OS modifications? isn't this just going be 'chrome' (or 'other application') asking for a udp socket and spewing line-rate-foo out of that? isn't the application going to be doing all of the multiplexing and jankiness? I hope not. What would be the point of only letting one application take the benefit of all those improvements? If we're able to identify clear performance wins, our hope is to collaborate with the rest of the community to develop the features and techniques of QUIC into network standards. So yes, QUIC itself doesn't require OS-level modifications, but letting stay there is pointless. protocol that could be similar to UDP but work on the application layer. it's not 'similar to UDP', it is in fact UDP, from what I read in the article. Well, it runs on top of UDP, but it is NOT UDP. My guess is that UDP is needed just to work through NAT. My point was that all that work could be focused on a *really* good transport (even with end-user multihoming without bloating the routing how's that sctp going for you? lisp? sham6? That's the point exactly. Google has more power and popularity to influence adoption of a protocol, just like with SPDY and QUIC. Neither of the three are widely implemented. That said, neither of those enable full path resiliency. Path resiliency requires the end-point to be available through different paths and being able to detect those paths *before* the first connection is established. SCTP is not NAT friendly (to the best of my knowledge), SHIM6 is IPv6-specific and can help you recover an already successful connection. LISP... I can't still grasp LISP, although it doesn't have anything to do with multihoming. :-) table), and have streamlined TCP and UDP that takes advantage of the new protocol. sure, ilnp? ILNP is new for me. Looks interesting, thanks. -- Octavio.
Re: Google's QUIC
On Fri, 28 Jun 2013 17:20:21 -0700, Christopher Morrow morrowc.li...@gmail.com wrote: Runs in top of UDP... Is not UDP... If it has protocol set to 17 it is UDP. So QUIC is an algorithm instead of a protocol? SCTP is not NAT friendly (to the best of my knowledge), SHIM6 is IPv6-specific and can help you recover an already successful connection. LISP... I can't still grasp LISP, although it doesn't have anything to do with multihoming. :-) Lisp is actually very much about multihoming... In fact that was one of the key reasons it got started. It actually could make multihoming and mobility very much simpler at the applications if it were used. Yeah, but LISP is as [in]accessible to end-users as BGP is and it will be like that forever. It requires ISPs to opt-in to provide this. LISP is not a universal option. LISP matters to the Internet core, it doesn't matter to the whole Internet. It is just not universal. ILNP is new for me. Looks interesting, thanks. Mind that ilnp is v6only also requires stack changes... I just read about ILNP. ILNP is nice if you want to multihome nodes, but virtualization (or spanning, for that matter, similar to anycasting) over multiple data-centers will reach the limitations of ILNP. It is a step ahead, but it is not an integral approach. I wish my Debian mirror would just be the mirror.debian.net *service* (not host), and the network could choose the best for me. -- Octavio.
Re: Please, talk me down.
On Tue, 16 Oct 2012 20:35:11 -0700, Joseph Anthony Pasquale Holsten jos...@josephholsten.com wrote: I want to like IPv6. I do. But I'm seriously considering turning off IPv6 support from our servers. First off, I'm using djbdns internally and it doesn't support records. So we really aren't using it internally. But today I noticed that we have a lot of traffic to our DNS cache, and started to investigate. Turns out that every DNS request would start with one for the record. Ah, no luck. Maybe you forgot the search domain? Let's retry that DNS request with that tacked on. Failed again? Meanwhile, lets simultaneously try for the AA record then. Repeat. I'm _this_ close to turning IPv6 off entirely. Anyone want to talk me off this ledge? You will eventually have to turn it on again, so you may run away from the problem that will catch you up anyway or, better, start tackling the problems, like fixing djbdns or replacing it with something that works. That's my way of seeing it. Good luck with it. -- Octavio. Twitter: @alvarezp2000 -- Identi.ca: @alvarezp
Re: Big Temporary Networks
On Thu, 13 Sep 2012 14:45:55 -0700, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Måns Nilsson mansa...@besserwisser.org 04:05:41PM + Quoting Dylan Bouterse (dy...@corp.power1.com): I'm not sure if this is obvious for this list or not, but with your WiFi nodes, a good practice for that kind of density is more nodes, lower power. Keep the client connection load per AP as low as possible to improve overall performance. Jacking up the power in a small area like that will just step on the adjacent APs and cause issues. I'd have expected someone to have QoS mentioned already, mainly to put FTP and P2P traffic on the least important queues and don't hog up the net. -- Octavio. Twitter: @alvarezp2000 -- Identi.ca: @alvarezp
Re: VPN over satellite
On Mon, 30 Apr 2012 02:42:27 -0700, Rens r...@autempspourmoi.be wrote: Could anybody recommend any hardware that can build a VPN that works well over satellite connections? (TCP enhancements) I'd try splitting the solution into two devices: at the lower layer, the tunneling part, which can be done with any traditional transport-layer VPN solution; at the higher layer (prior to encryption), the TCP enhancement part, for which, I'd look for dedicated and specialized multipoint WAN optimization devices. I want to setup a L3 VPN between 2 satellite connections That's brave! I'd check with the satellite provider if they are able to forward your frames directly from VSAT to VSAT without going through the hub, and, if multiple satellites are used, if they can route between satellites. Most don't. Those two above are NOT easy to do. They will most probably make your packets double-hop, so your latency will be about 1.4 seconds. -- Octavio.
Re: shared address space... a reality!
On Tue, 13 Mar 2012 23:22:04 -0700, Christopher Morrow christopher.mor...@gmail.com wrote: NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName:SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED Weren't we supposed to *solve* the end-to-end connectivity problem, instead of just letting it live? Sure, this lets CGN to be more organized for operators, but those that already have RFC5735 addresses implemented will not switch to 100.64/10 just because there's a new block. Only new players will actually benefit from this. It will only make it easier for new players to play in IPv4 instead of being pushed to IPv6. -- Octavio.
Re: facebook lost their A-record for www.facebook.com?
On Tue, 06 Mar 2012 23:43:07 -0800, Igor Ybema i...@ergens.org wrote: [igor@vds ~]$ host -t A www.facebook.com ns1.facebook.com Using domain server: Name: ns1.facebook.com Address: 204.74.66.132#53 Aliases: www.facebook.com has no A record No, it's a subdomain with its A records in another server. $ host -t A www.facebook.com glb1.facebook.com. Using domain server: Name: glb1.facebook.com. Address: 69.171.239.10#53 Aliases: www.facebook.com has address 69.171.224.12 Try dig +trace www.facebook.com to see why. -- Octavio. Twitter: @alvarezp2000 -- Identi.ca: @alvarezp
Re: Common operational misconceptions
On Wed, 15 Feb 2012 12:47:15 -0800, John Kristoff j...@cymru.com wrote: I have a handful of common misconceptions that I'd put on a top 10 list, but I'd like to solicit from this community what it considers to be the most annoying and common operational misconceptions future operators often come at you with. The idea that the more access-points, the better our WiFi. Oh, and the use of RJ45 for the unconfigured 8P8C, but this is not that annoying. Cheers.
Re: Speed Test Results
On Fri, 23 Dec 2011 01:18:40 -0800, jacob miller mmzi...@yahoo.com wrote: Am having a debate on the results of speed tests sites. Am interested in knowing the thoughts of different individuals in regards to this. They are just a measurement, which need to be correctly used and interpreted (that's the difficult part). Reading bad numbers is not necessarily an indication of a link problem. Reading good enough numbers is only meaningful for the duration of the test. To me, the big problem is that they don't state all the details of the tests (for example, how exactly to they do the transfer). Geographical location is good, but sometimes not enough. Do they use http, https, ftp or their own JS implementation of whatever weird protocol they though of? How do I know if I'm hitting my firewall, web cache or ALG? I only use them to get a generic overview of the link. -- Octavio. Twitter: @alvarezp2000 -- Identi.ca: @alvarezp
Re: IPv6 - a noobs prespective
On Wed, 09 Feb 2011 03:00:27 -0800, Robert Lusby nano...@gmail.com wrote: I am however *terrified* of making that move. There is so many new phrases, words, things to think about etc You fears will significantly lower after you set up a separate lab and play with it. With something as simple as a switch you can make a simple IPv6-only network. Try to replicate your current network in the lab as far as you can, using the new concepts and techniques and understand the current state of the art (read that as RA+DHCPv6, etc.) Get your pings right. This will automatically get you to dual-stacking, as in how do I make both protocols work in the same physical network?. They just do. At this point the problem stops belonging to the network infrastructure and it passes on to the application servers and hosts. (And ask your ISP to support IPv6). Good luck. -- Octavio.
Re: AAAA on various websites, but they all forgot to enable them on their nameservers....
On Wed, 08 Jun 2011 02:28:40 -0700, Jeroen Massar jer...@unfix.org wrote: It is really nice that folks where able to put records on their websites for only 24 hours, but they forgot to put in the glue on their nameservers. As such, for the folks testing IPv6-only, a lot of sites will fail unless they use a recursor that does the IPv4 for them. In fact. Although a website of mine worked flawlessly in a dual-stack but it did NOT in an IPv6-only environment. Unfortunately, the problem has to be fixed in the DNS provider, which though supporting records was enough to support IPv6. dig -6 +trace is our friend here. -- Octavio.
Re: How do you put a TV station on the Mbone? (was: Royal Wedding...)
On Sat, 30 Apr 2011 10:34:15 -0700, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Octavio Alvarez alvar...@alvarezp.ods.org said: So the first user in a router tunes to a multicast stream. Consumption for the ISP and all the routers in the chain to the source: same as if it were a unicast stream. Then a second user tunes to a multicast stream. Cost for the ISP: zero. How does this affect peering, when some providers want bandwidth ratios in a certain range? I can also see how this affects the ISPs providing bandwidth to the content providers. In our colo for example, we rate-limit customers to the paid-for bandwidth at the colo port. With multicast however, they could use significantly more bandwidth, because every router in our network could potentially send the stream to many ports. You are billing your content provider for the bandwidth consumption at his port not because you intend to bill him for the bandwidth of content provided, but for the bandwidth of content delivered to the end user! The end-user is ALREADY PAYING for that bandwidth! Something is *really* broken there. -- Octavio. Twitter: @alvarezp2000 -- Identi.ca: @alvarezp
Re: How do you put a TV station on the Mbone? (was: Royal Wedding...)
On Fri, 29 Apr 2011 10:48:51 -0700, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Rubens Kuhl rube...@gmail.com And that's the snap answer, yes. But the *load*, while admittedly lessened over unicast, falls *mostly* to the carriers, who cannot anymore bill for it, either to end users, providers, *or* as transit. Will they not complain about having their equipment utilization go up with no recompense -- for something that is only of benefit to commercial customers of some other entity? Why would they bill someone for a service they are already providing? So the first user in a router tunes to a multicast stream. Consumption for the ISP and all the routers in the chain to the source: same as if it were a unicast stream. Then a second user tunes to a multicast stream. Cost for the ISP: zero. So 5000 users connect each to a different multicast source. It is the same as if they all used unicast. The utilization can never be worse than a unicast-only network. So maybe I'm oversimplifying, but I fail to see a problem, only an artificial one created for the sake of it. Other than the potencial CPU load of the routing protocol, I even fail to see the commercial value of not providing multicast.
