Re: maximum ipv4 bgp prefix length of /24 ?
On 02/10/2023 19:24, Matthew Petach wrote: The problem with this approach is you now have non-deterministic routing. Depending on the state of FIB compression, packets *may* flow out interfaces that are not what the RIB thinks they will be. This can be a good recipe for routing micro-loops that come and go as your FIB compression size ebbs and flows. Had NOT considered the looping - that's what you get for writing in public without thinking it all the way through *blush*. Thanks for poking holes appropriately, Tim.
Re: Dual stack IPv6 for IPv4 depletion
> And I’m saying you’re ignoring an important part of reality. > > Whatever ISPs default to deploying now will become the standard to which > application developers develop. > > Changing the ISP later is easy. I'm not even convinced of that. Once "/56" (or *any* value) is baked into the processes, hard-coded in systems all over the shop, assumptions made left, right and centre throughout the business, changing it will be hard. Only the tech part of changing the ISP is easy. It's the same reason it's so difficult to get IPv6 moving in some ISPs. Making the kit dance the appropriate jig in (modulo a few Luddite vendors and legacy kit that Just Won't Die) is quite straight-forward. Getting IT to update a field to not force [0-9]{1,3}.[0-9]{1-3}.[0-9]{1,3}.[0-9]{1,3}, or to add a new field, without a revenue stream attached is *hard*. (Yes, it's part of our job as technologists to explain why we should do it anyway. That doesn't stop it being hard.) Regards, Tim.
Re: Residential VSAT experiences?
> Interesting that you say that about sip. We had a client that would use it > for sip on ships all the time. It wasn't the best but it worked. Ping times > were between 500-700ms. It really depends on your expectations - or more to the point, your end-users' expectations. I've tested SIP in the lab up to 2000ms RTT. The protocols all hang together and keep working, but it's obviously very much in walkie-talkie mode, you can't hold a normal duplex conversation. 500ms there's more of the talking over each other / "sorry, you go" / "no, you go" dance, but it *is* workable. If your end-user is expecting land-line replacement though... Regards, Tim.
Re: Alcatel-Lucent 7750 Service Router (SR)
> It really bothers me to see that people in this industry are so worried about > a change of syntax or terminology. If there's one thing about the big > vendors that bothers me, it's that these batteries of vendor specific tests > have allowed many "techs" to get lazy. They simply can't seem to operate > well, if at all, in a non-Cisco (primarily) environment. I'd half-agree :) Making "it's different" in and of itself a reason not to use a particular vendor does seem to head towards laziness. But with the best will in the world, your good engineers *will* be slower until they familiarise with the new mind-maps (particularly things like the logical/physical split, SAPs, etc on the ALU) and the new magic words - although hopefully they'll be excited to learn something new too. Your weaker engineers are going to need more of a push and/or some help, and the further towards helpdesk and scripts you get, the more you're going to need to provide training - be that internal, external, new scripts and cribs sheets or whatever. That's an impact and cost it's unwise to ignore. Regards, Tim.
Re: Alcatel-Lucent 7750 Service Router (SR)
> I am worried as most tech's know Cisco and Juniper, so going to ALU would > be a learning curve based on replies I am getting off list. It's definitely quite different from the CLI. I'm still dabbling, but the guys here who have been through the training and are immersed in it really like it. We're using a couple for feature-rich BNG - lots of MLPPP at high bandwidths (for broadband), heavyweight QoS, BGP to the CE, etc. It's very controllable by RADIUS - template configs that you can fill in the values for, rather than the Cisco approach of AVPs with pages of config in. ALU have an e-learning "SR-OS introduction" course, which is going down pretty well for jump-starting our Ops people. Regards, Tim.
Re: Fixing Google geolocation screwups
> That all said: Restricting content based on location is complete and > utter nonsense in 2015. The world is global, people want to pay for > content and the content owners just don't allow people to pay for it. Globalisation is for your corporate lords and masters to buy labour and raw materials where they're cheap. If mere peons try to buy goods and services in the same way, expect to be crushed by the best legislation money can buy :( Regards, Tim.
Re: Verizon Policy Statement on Net Neutrality
> I meant that on the Internet as a whole it is unusual for such speeds to > actually be realized in practice due to various issues. > > 8-10Mb/s seems to be what one can expect without going to distributed > protocols. Really? I have 2 x VDSL (40/10) to my house, running MLPPP. I can get a sustained 60M down or 15M up on a single stream without a lot of difficulty. It does typically need both ends to be aware of window scaling, or you start to run up against the LFN problem, but other than that it's nothing beyond regular HTTP, FTP, SCP, CIFS, ... 15M upstream *utterly* transforms working from home where all the files I'm working on are on a remote file server. Autosave is no longer a cue for a 5-10 minute tea-break. Regards, Tim.
Re: Recommended wireless AP for 400 users office
> That's it. Step 1, buy the equipment at full price. Step 2, pay for the cloud > management license, yearly. Step 3, no extended warranty option, so pay full > price if equipment from step one fails. As long as you're doing step 2 (which you *have* to, otherwise it's a brick), isn't step 3 "report device as failed, new device shipped to site, plug in cable, sucks down config of old device from the cloud, up and running again"? I only so far have the demo gear from one of their (rather good) training courses, which has a couple of years left to run, rather than any live deployments, but that's my understanding of the support model from the meetings I've had with them to date. Regards, Tim.
Re: HTTPS redirects to HTTP for monitoring
> By the way, I hope that all of the people who have been ranting about > this have read this note. The only way this filtering works is if the > client computers have a special CA cert installed into their browsers. > That means it's a private organizational network that manages all its > client computers, or it's a service where the users specifically do > something on their own computers to enable it. In the first instance, I'd still very much *want* the organisation to tell the users that the internal IT people are breaking their SSL, so please not to have any expectation that security is doing what you think it is. While it's not an organisation I'd particularly enjoy working for, at least I then know not to do online banking in my lunch break, or similar. Pushing out internal MITM CAs silently *is* still evil, in my view, although sadly closer to what I'd *expect* to happen. Regards, Tim.
Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]
> All those init.d scripts do about 95% the same thing, all hacked > together in shell. Most of them are probably just slightly edited > versions of some few paleo-scripts. > > Set the location of the pid file, set the path of the executable, set > the command line flags/options, maybe change some flags/options based > on some options in another file like /etc/sysconfig/daemon_name (also > shell commands which are just executed inline), then the > start/stop/reload/restart/status case statements. And the dependencies > of course. > > It really could just be config files like xinetd or logrotate except > for a few hard cases where you could have a "run this script" > attribute. Replacing "run these scripts in the right order" with a config-driven "service manager" sounds like a sensible development. (Not necessarily the One True Way, but certainly an option). Pulling complicated things like chroot, capabilities etc into one place, getting them right, and then letting services specify what they want, rather than everyone having to re-invent the same shell scripts sounds like it would encourage use of those features. I can even see some more advanced functionality to specify checks / frequencies for "is this service still running / alive" that effectively moves a lot of watchdog functionality into the "service manager". I'm somewhat confused (without reading the implementation details, just conceptually) as to why the "service manager" is also providing DHCP client, SNTP client, virtual consoles, session management... I can completely understand why the "do one thing" crowd are taking objection to that. Regards, Tim.
Re: misunderstanding scale
> Additional support on my feeling of DO and IPv6, is DO's stance of > directly not even allowing IPv6 tunnels to HE, SiXXs, or any of the > other providers by specifically teliing them not to allow connections > from your IPv4 address space. Say *what*? I've got HE tunnels into DO, purely because they won't get their finger out and offer native v6, but the rest of the service currently outweighs the hassle of tunneling. If this is going to get blocked, I'll be reversing the migration of my existing VPS services elsewhere *into* DO, and starting to look for yet-another provider :( I've already had a rather strange conversation with SIXXS where they swore seven ways from Sunday I couldn't have a tunnel because DO already offer native v6, despite sending them numerous official statements to the contrary, but trying to reason with SIXXS is always "interesting"... Regards, Tim.
Re: [nznog] Web Servers: Dual-homing or DNAT/Port Forwarding?
> Just because something is public doesn¹t mean you have to accept ALL > traffic, it just means you have to anticipate any potential problems based > on Larry knowing your address rather than imagining him standing at the > front gate of your gated community. ;) (let¹s torture that analogy!) There's still a gated community? I thought that particular piece of routing joy was long gone... Sorry, I'll get my coat. Tim.
Re: Reverse DNS RFCs and Recommendations
> I've never seen anyone put in rDNS for networks or broadcast addresses. I've done this a fair bit, on both a personal and professional basis. I find it quite helpful when I forget what the subnet masks are (or fail to apply them properly) and try and Do Something with an address that can't be a host. Regards, Tim.
Re: Gmail and SSL
> http://www.startssl.com/ > > Their certs are free and, from what I hear, are accepted by Google. Seconded. I was a hold-out for a long time on personal stuff - I trust me, I'm not paying someone else to trust me - but StartSSL makes a lot of the pain go away with minimal effort. Regards, Tim.
Re: IP tunnel MTU
>> Certainly fixing all the buggy host stacks, firewall and compliance devices >> to realize that ICMP isn't bad won't be hard. > > Wait till you get started on "fixing" the "security" consultants. Ack. I've yet to come across a *device* that doesn't deal properly with "packet too big". Lots (and lots and lots) of "security" people, one or two applications, but no devices. Regards, Tim.
Re: guys != gender neutral
> Given the lack of truly neutral terms in english, I have > taken to alternative my pronouns interchangably when I write. "Folks"? I really do mean "folks" when I write "guys", but I do understand why it can come across as exclusionary, and I try to force myself into the habit of "folks". It sounds a bit odd in English, although not as archaic as "chaps", which I'm also guilty of; I'm assuming there's no additional cultural assumptions attached to "folks" in American? Cheers, Tim.
Re: The Department of Work and Pensions, UK has an entire /8
> So...why do you need publicly routable IP addresses if they aren't > publicly routable? Because the RIRs aren't in the business of handing out publicly routable address space. They're in the business of handing out globally unique address space - *one* of the reasons for which may be connection to the "public Internet", whatever that is at any given point in time and space. RIPE are really good about making the distinction and using the latter phrase rather than the former. I'm not familiar enough with the corresponding ARIN documents to comment on the language used there. Regards, Tim.
Re: Big Temporary Networks
> You'll need a beefy NAT box. Linux with Xeon CPU and 4GB RAM minimum. Or not. The CCC presentation is showing *real* Internet for everyone, unless I'm very much mistaken... Regards, Tim.
Re:
> Does anyone have a very lightly used, long long low bandwidth link > they can dedicate to The Cause? Dummynet. One cheap PC, two NICs, roll your own, as long as you like. I've had fake circuits running with 2s RTT, applications keep doing their thing, just very slowly. Regards, Tim.
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
> The only solution is, IMO, to let multihomed sites have > multiple prefixes inherited from their upper ISPs, still > keeping the sites' ability to control loads between incoming > multiple links. And for the basement multi-homers, RA / SLAAC makes this much easier to do with v6. The larger-scale / more mission-critical multi-homers are going to consume an AS and some BGP space whether you like it or not - at least with v6 there's a really good chance that they'll only *ever* need to announce a single-prefix. (Ignore "traffic engineering" pollution, but that doesn't get better or worse). Regards, Tim.
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
> Even though it may be easy to make end systems and local > LANs v6 capable, rest, the center part, of the Internet > keep causing problems. Really? My impression is that it's very much the edge that's hard - CE routers, and in particular cheap, nasty, residential DSL and cable CE routers. Lots of existing kit out there that can't do v6, and the business case for a fork-lift upgrade just doesn't stack up. It's a cost issue, though, not a technology one - it's perfectly possible to deliver v6 over these technologies. Tunnelling, while not ideal, is certainly a workable stop-gap, and I'm *very* happy to have real, globally uniquely addressed end-to-end Internet in my house again as a result. Systems can be a problem too - both in convincing IS people to change things, in getting the budget for changes, and in finding all the dark places hidden in the organisation where v4 assumptions are made. But in the Internet core? I don't see any huge obstacles at $ISP_DAYJOB, with any of the people I know in the industry, or with the ISPs I do business with. For co-lo, VPS, leased lines, real Ethernet tails, v6 connectivity is being delivered and working fine today. Regards, Tim.
Re: Quad-A records in Network Solutions ?
> Not to sound like I am trolling here, but how hard is > it get VPS servers or some EC2 servers and setup your > own DNS servers. Are there use cases where that is not > practical? Aren't we talking about NetSol as a *registrar* and inserting quad-A glue? Or did I miss the original intention? Regards, Tim.
Re: Shim6, was: Re: filtering /48 is going to be necessary
> I don't think the term means what Masataka thinks it means, because nobody > in this discussion is talking in terms of circuits rather than packet routing. Geographical addressing can tend towards "bellhead thinking", in the sense that it assumes a small number (one?) of suppliers servicing all end users in a geographical area, low mobility, higher traffic volumes towards other end-users in the same or a close geography, relative willingness to renumber when a permanent change of location does occur, and simple, tightly defined interconnects where these single-suppliers can connect to the neighbouring single-supplier and their block of geography. I'm not sure he's right, but I think I understand what he's getting at. Regards, Tim.
Re: Huawei edge routers..
> On the other hand, if you hop into other people's Huawei > routers via CLI you will curse and scream. As close as I > could tell, it handles most functionality of IOS, but > they tried to find a synonym for every word cisco used > in the cli. This does occasionally brighten up my day with gems like "rip no work" and "reset-recycle-bin", so it's not all bad :) Regards, Tim.
Re: dns and software, was Re: Reliable Cloud host ?
> GAI/GNI do not return TTL values, but this should not be a problem. > If they were to return anything, it should not be a TTL, but a time() > value, after which the result may no longer be used. > > One way to achieve that would be for GAI to return an opaque structure > that contained the IP and such a value, in a manner consumable by the > sockets API, and adjust connect() to return an error if passed a > structure containing a ' returned time + TTL' in the past. AF_INET_TTL and AFINET6_TTL, with correspondingly expanded struct sockaddr_* ? Code that explictly requests AF_INET or AF_INET6 would get what it was expecting, code that requests AF_UNSPEC on a system with modified getaddrinfo() would get the expanded structs with the different ai_family set, and could pass them straight into a modified connect(). I'm sure I'm grossly oversimplifying somewhere though... Regards, Tim.
Re: WW: Colo Vending Machine
> PC LOAD LETTER?!?!?!?!? PC LOAD LETTER is not the issue. One country that insists on using different paper sizes to everyone else, but also happens to set a lot of hardware and software defaults is the issue :(
Re: Common operational misconceptions
> When I took an A level computing course in the 90s the course material > still talked about primary stor and backing stor, batch jobs and the > like... I was working with a lot of batch jobs in my first development role in 1993, and still supporting overnight scheduling to make best use of the Cray by 1999. I still leave the occasional big data set crunching overnight now. I'll grant you it's not exactly mainstream computing, but it's not exactly up there with drum memory either... The concept that a computer can do things when a person isn't there, or without the need for clicking things, is probably not a bad one to impart. Regards, Tim.
Re: enterprise 802.11
> As for the iOS problem, read on here: > http://www.net.princeton.edu/apple-ios/ios41-allows-lease-to-expire-keeps-using-IP-address.html That's the iOS issue - out of curiosity, what's the Mac issue? Regards, Tim.
Re: AD and enforced password policies
> There is indeed a difference between Europe (or is it only .SE?) and > USA here; no bank in Sweden lets you login without at least a client > certificate and password/pin code. Most banks have a hardware token, > either challenge-response or HOTP/TOTP; some use the chip in chip-and-pin > cards as certificate carrier, and combine it with a reader device to > manage pin code entry. Can't speak for Europe as a whole, but certainly in the UK it's not common - and I wish it was. I do have different passwords for my banking and other finance-type sites (pensions etc), both for each site and distinct from my "fuzzykittens" passwords (which do re-use a handful of variations on a couple of themes). A hardware token would be very nice though. Client cert worries me a bit - while it *should* be standards-based, I'm sure there's some way to implement it such that it only works on Windows. Given how long it took for banks to stop with the "Safari! Evil! Access denied!" routine, I don't hold much faith in their willingness or ability to build cross-platform solutions. Grumble for the day: Santander, who require so many different IDs, logins, codes, reference numbers etc to access their on-line services with no indication at all of how any of them relate to the documentation previously sent or any changes made since, that there's no way to deal with it other than to write them down. Oh, and some more different codes, with more different names, to access the same account by telephone. Strongly not recommended. Regards, Tim.
Re: Dynamic (changing) IPv6 prefix delegation
>> 3) If you write an application using anything other than UDP or TCP, >> it won't work on most networks (with some minor exceptions for PPTP >> and IPSEC, which work sometimes). > > This hasn't been my experience unless you're behind some form of NAT. > Yes, it is well known that NAT breaks most protocols. I've come across a non-zero number of "residential" providers, who, with or without NAT, explicitly discard protocols 50 and 51. The same argument is applied - if you want this, you must buy a "business" connection. Which is usually double-speak for "add an order of magnitude to the price, turn off *some* of the broken-ness". Regards, Tim.
Re: Performance Issues - PTR Records
> It's already been pointed out that lame delegations are more likely > problems for many. But the "we'll just pre-fill in-addr to avoid > problems" isn't going to work for ip6.arpa. If anyone has enough > hardware to serve the zone for a /48 (64k * 4bil * 4bil * > bytes-in-record), I'd love to see it. :) If PTR exists in zone file, serve it. Else, synthesize generic reverse. Jobsagoodun. > We need to get web and app folks to stop counting on > ip6.arpa/in-addr.arpa as a validation of trustworthiness. PTR make some > sense for validating servers, MTAs, etc. and it's handy for traceroute > but it was never a great tool and it's getting less useful with time. I've always seen it as a reasonable indication of a) minimum level of clue and b) giving a damn. If you can't be bothered or don't know how to provide even basic generic rDNS for your network, there's a reasonable chance you're lacking in other areas of network / user management. (Not "you" personally, of course). Regards, Tim.
Re: IPv6 end user addressing
> Silly confidentiality notices are usually enforced by silly corporate > IT departments and cannot be removed by mere mortal employees. > They are an unavoidable part of life, like Outlook top posting and > spam. Alternatively, if your corporate email imposes stupid policies and / or a stupid email client (note: it's possible to quote properly and not top-post with Outlook, it's just hard work), don't subscribe to mailing lists from your corporate email. Of all the mailing list communities, I'd expect this one not to struggle very much with arranging an alternative... Regards, Tim.
Re: best practices for management nets in IPv6
> You can also use IPv6 privacy extensions (by default on Windows 7), > see rfc4941. For Linux, you can also enable it, which is not a > default. In the context of "addresses I'm using to manage kit", having devices randomly renumber themselves at regular intervals does *not* sound like it's going to make my life easy :( Regards, Tim. _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: NANOG List Update - Moving Forward
- Original Message - > The new posts do not have list (un)subscribe information in the > headers. Also, a statement would be nice as to what header definitely *will* be in place that we can filter on. At the moment, I'm assuming 'List-ID', but I'm not sure if that header or its contents can be relied on. Regards, Tim.
Re: NANOG List Update - Moving Forward
> Thankfully, the current test has been a success. Including stopping non-members from posting to the list, and other anti-spam? I've got a sudden influx this morning of spam addressed to nanog@nanog.org :( Regards, Tim.
Re: The stupidity of trying to "fix" DHCPv6
> Standing back a little, I can see an argument that IPv6 would be an > easier 'sell' if there were two modes of operation, one with only > RAs, and one with only DHCPv6. This +1. There are plenty of enterprises, employing actual network engineers (allegedly), who are just about getting to grips with CIDR and VLSM. They are *thinking* about reconfiguring their hosts to stop having 10.x.x.x/8 as the interface address, and letting proxy-arp on the routers worry about which subnets are which. They *might* have been convinced that an ATM cloud (or sometimes even MPLS!) has robust traffic separation, and they don't need a full mesh of leased lines any more. IPv6 is hugely scary as it is, without breaking their "hosts and host info" / "routers and routing info" silo model. Not all of the networking world runs on Internet time :( Regards, Tim.
Re: Hotmail?
> Let me just step in here and say.. it's tough to build onto Zimbra. > At work, we support ~1000 users on Zimbra (network edition), with > hundreds of thousands of messages flowing through daily, and it > doesn't like you tinkering with stuff under the hood. Most of your > customizations get blown away when you upgrade. That said, I know > of some organizations who customize it like crazy (I had heard that > Lycos's free mail system is Zimbra-based, and Yahoo as well). > Once you deviate, though, don't expect to stick to Zimbra's > releases. Seconded. In terms of functionality and interface, I like Zimbra a lot, but they make Microsoft and Apple look like amateurs in the "our way, or not all" game. As a small friends-and-family installation, I can't afford to dedicate a whole box exclusively to Zimbra[0], and trying to make it play nice with anything else running on the same server is a pain. As you say, pretty much anything that they don't have a GUI setting for is a nightmare to keep working across upgrades. I'd imagine it's actually better if you're planning a bigger-scale deployment and can have the architecture a lot more in line with how they expect it to be from the start. Regards, Tim. [0] OK, I probably could now with a VM, but the virtualisation support on my hosting box wasn't really there when I started...
Re: How do you put a TV station on the Mbone?
> I think that George's POV -- which is also mine -- is that as the > world shifts, the percentage of video distribution which is > amenable to multicast, and not well served by unicast, is likely > to grow, and it would be a Good Idea to be ready for that > situation already when it arrives. Really? If anything, I'd say quite the opposite. Watching media in the time-slot that someone else has decided on is *so* 20th-century - I can't remember the last time I sat down to actively watch a programme in its original transmission slot. (As opposed to having the TV on as background, e.g. 15 minutes of breakfast news in the morning). I guess multicast to a recording application (or appliance) might work - but essentially my requirement is strongly skewed towards video-on-demand. I have absolutely zero interest in sport of any kind though - I'm given to understand there's quite a high demand for live viewing of that. Regards, Tim.
Re: Bubba is a 75 year old woman looking to make some extra cash
> I guess we have another gem for DeLongFacts.com (in the vein of > SchneierFacts.com): He is one of the few natural enemies of the > Babushka. Did anyone else suddenly have flashbacks to the VMS Wombat?
Re: What vexes VoIP users?
> I do not live over there, I have never seen a Vonage or Magic jack or > any other VoIP service ad on TV in the UK, ever. Vonage *are* advertising on UK TV. Hardly the carpet-bombing the OP suggests is the case in the US, but they are doing something. > It is quite a different market here. I can get POTS services over the > same copper from, I'd say, about 5 different companies. Maybe more, I > have not counted. I guess the competition already available on the > copper would largely preclude anything but the cheapest VoIP service. For UK national calls, which pretty much all the POTS providers are offering for "free" (read "bundled"), I tend to agree - especially given that the POTS providers who *aren't* BT (Residential) are largely having to lease at least the last mile copper from BT (OpenReach). The Vonage TV ads that I've seen in the UK are pitched at offering cheap / free / bundled international calls, and the target market for that I believe is both different and smaller. Regards, Tim.
Re: quietly....
> So, when I take my laptop from Home to work, to the airport, to some > random cyber cafe I should have to manually alter my DNS servers > assuming I can find someone in the location who can tell me what they > are ?? Or let me guess, I should hardcode some public DNS servers > which I can hopefully reach from where I am, hopefully is not down or > having issues and hopefully I don't have poor latency to? You could always run your own recursive server on your laptop, instead of a stub, and remove your dependancy on anyone but the roots. *ducks* Regards, Tim.
Re: Using IPv6 with prefixes shorter than a /64 on a LAN
> I think ULA is still useful for home networks. If the home router guys > properly generate the ULA dynamically, it should stop conflicts within > home networking. There's something to be said for internal services > which ULA can be useful for, even when you do fall off the net. I really, *really* expect my CPE router *not* to remove global addresses from the LAN interface(s) when the link to the Internet goes down. My internal services should go on working with their global addresses. This is how my tunneled IPv6 works today. Am I being an unreasonable engineer in this respect? Regards, Tim.
Re: PPPOE vs DHCP
> 10K isn't supporting IPv6 on PPPoE? I thought the 10K specialized in > utilizing the IOS SR line. I've played with PPPoE and bridging on the > 7200s mostly. I need to kick up an ASR, as I hear it's specialized > code line has much better IPv6 support than IOS SR. both XR/XE codes > seem to be much more richly featured, especially for radius backending > DHCP. So they're telling us, at least for PPPoE specifically. Cisco solution is "buy ASR". Regards, Tim.
Re: PPPOE vs DHCP
> Terminating PPPoE generally isn't much different than terminating > VLANs. In Juniper world, it requires the right equipment. Cisco > world, it's not generally a big deal. Unless, for example, you already sunk a chunk of change into Cisco 10Ks, and now want IPv6 on your PPPoE. Not that I'm becomming increasingly bitter about that platform or anything... Regards, Tim.
Re: Some truth about Comcast - WikiLeaks style
- "Owen DeLong" wrote: > Yeah... I'd rather see it done in such a way that there is a > prohibition of common ownership or management. Essentially, > require that the stock be split and each current owner receives > one share in each company with any shareholders who own more than 3% > of the companies having 180 days to divest from one company or the > other, or, reduce their total investment in both below 3% with a > requirement that the infrastructure provider not retain any portion > of the name of the original company and no relationship other than > supplier to the service provider company. > > Obviously, this probably won't happen. The Telcos in the US have far > too powerful a lobbying force, but, I think that would be the best > thing for the consumers. Presumably for both the consumers *and* every company involved in network services who doesn't have the luck of a historical last-mile monopoly. Regards, Tim.
Re: Some truth about Comcast - WikiLeaks style
- "Owen DeLong" wrote: > Personally, I think that enforced UNE is the right model. If you sell > higher level services, you should not be allowed to operate the physical > plant. The physical plant operating companies should sell access to the > physical plant to higher level service providers on an equal footing. To all intents and purposes what we have in the UK. BT, the old, formally government-owned, then privatised, effective last-mile monopoly, was split up. (I believe in return for some more government cash to build infrastructure, but I could be wrong on the order of events). BT OpenReach is now responsible for wires on poles / in the ground, CO space etc, and has to sell access to these to other divisions of BT (Wholesale, Residential) in the same arms-length way they sell them to other ISPs. It doesn't always work *quite* like that, especially in respect of actually getting space and power in COs, but the framework is there... Regards, Tim.
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
> About the only hack I can see that *might* make sense would be that > home CPE does NOT honour the upstream lifetimes if upstream > connectivity is lost, but instead keeps the prefix alive on very > short lifetimes until upstream connectivity returns. Yep, that's the hack I was getting at. As a non-technical end-user, once my CPE has got a prefix from my ISP and advertised it to the devices on my LAN, the same prefix should keep working until: -my ISP assigns a different one -the end of time whichever comes first :) Having my PC not be able to talk to my printer any more because my DSL / cable / wimax / whatever has been down for "too long" is not acceptable. Regards, Tim.
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
>> Your home gateway that talks to your internet connection can either >> get it via DHCP-PD or static configuration. Either way, it could >> (should?) be set up to hold the prefix until it gets told something >> different, possibly even past the advertised valid time. > > That breaks the IPv6 spec. Preferred and valid lifetimes are there > for a reason. And end-users want things to Just Work. The CPE vendor that finds a hack that lets the LAN carry on working while the WAN goes away and manages to slap the "With Home Network Resilience!" label on the box correctly will presumably do quite nicely out of it. For this kind of site, I can't see what is *actually* going to break if the CPE keeps sending RAs for the prefix beyond the valid lifetime while the WAN is down. As long as it advertises a short valid lifetime itself, such that if the real prefix changes[0] when the WAN comes back up it can renumber everything on the LAN quickly, it looks a lot like a "Just Works" scenario to me... Regards, Tim. [0] Which it won't, of course, because residential users are going to get proper static connections by default, rather than another round of "business class" price-gouging :)
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
> This isn't to do with anything low level like RAs. This is about > people proposing every IPv6 end-site gets PI i.e. a default free zone > with multiple billions of routes instead of using ULAs for internal, > stable addressing. It's as though they're not aware that the majority > of end-sites on the Internet are residential ones, and that PI can > scale to that number of end-sites. I can't see any other way to > interpret "we ought to make getting PI easy, easy enough that the > other options just don't make sense". OK, sorry, I think we're addressing different points of the same comment. I was looking very much at the second half of "all residential users get PI so that if their ISP disappears their network doesn't break", ie the reason *why* they'd want PI. I assumed that was "disappears" as in "has an outage", rather than goes bust, user changes ISP etc - and if you've only got one ISP, you don't need PI or ULA to have *local* connectivity work through an ISP outage. I agree, on the current routing platforms we have, PI for every end site is insanity. Whether we should be looking for routing platforms (or a different architecture - LISP?) that allows PI for every end user is a different question... Regards, Tim.
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
> Surely your not saying "we ought to make getting PI easy, easy enough > that the other options just don't make sense" so that all residential > users get PI so that if their ISP disappears their network doesn't > break? I've seen this last point come up a few times, and I really don't get it. If you're multihomed with multiple PA GUAs, yes, you'd want each RA to track its corresponding WAN availability so your devices are using a prefix that has connectivity. If you're a single-homed leaf network, why on earth wouldn't you want to generate RAs for your statically-assigned prefix all the time, regardless of the state of your WAN connection? Regards, Tim.
Re: New hijacking - Done via via good old-fashioned Identity Theft
> If i have to wait for 20 minutes for an email, i've started skype > already.. You know what, why don't we simply turn the smtp servers > -off- and use skype and msn for everything... saves electricity :P By that argument, why don't we turn off the Internet and use SMS for everything? > It may be a bit too late to fix the protocol itself to be real-time > and peer-to-peer again, but this time without spam ofcourse, as the > market has been flooded with better protocols already anyway (the > problem with these however is that they're propriatory and vendor > dependant). When was email *ever* expected to be real-time? If you need real time, use IM (the clue is in the "I"), or pick up the phone. Part of the beauty of email is that it doesn't require all participants to be connected at the same time, and everyone can deal with it when it's convenient to *them*, not convenient to the sender. Use the right communication tool for the right job. I can remember email being batch-transferred over dial-up lines, hop-by-hop, and taking hours or even days to cross the globe - and I'm a long way from being an Internet "old-timer". Regards, Tim.
Re: RIP Justification
- "Ruben Guerra" wrote: > Using BGP would be overkill for most. Many small commercial customers > to not want the complexity of BGP This one keeps coming up. Leaf-node BGP config is utterly trivial, and is much easier for the SP to configure the necessary safety devices on their side to stop you from shooting yourself in the foot and blowing up your networks - or worse, *their* network. Plus, if / when in the future you need to do something clever, you've already got the routing protocol with all the advanced knobs in place, ready for you to tweak as needed. The Enterprise guys really need to get out of the blanket "BGP is scary" mindset - running BGP for an SP with multitudes of customers, peers, transits, aggregation, filters etc and getting it right needs expertise and experience. Announcing a /24 LAN and receiving a default on a single link, not so much. > or want to spend money on extra > resources (routers that actually support it) This has a bit more weight to it, if you're at the really low end (certainly the consumer end). But a BGP-capable Cisco 800-series is, what, £300? Regards, Tim.
Re: RIP Justification
> Now, when traffic comes from head office destined for a site prefix, > it hits the provider gear. That provider gear will need routing > information to head to a particular site. If you wanted to use > statics, you will need to fill out a form each time you add/remove a > prefix for a site and the provider must manage that. Its called a > 'pain in the arse'. > > Enter RIPv2. Or BGP. Why not?
Re: RIP Justification
> I think BGP is better for that job, ultimately because it was > specifically designed for that job, but also because it's now > available > in commodity routers for commodity prices e.g. Cisco 800 series. +1 - for me, if I need a dynamic routing protocol between trust / administrative domains, it's BGP unless there's a good reason not to. I find it more straightforward to work with (albeit slightly more up-front to configure it and get it right) than anything else - the information available is a very clear "who am I talking to?" / "what routes do I send them?" / "what routes do they send me?". Plus I can work through the route-selection process by hand from the information displayed, and have it make sense. Regards, Tim.
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
> Competition would be wonderful, but is simply not practical in many > cases. Most people and companies don't want to hear this, but from > a consumer perspective the Internet is a utility, and very closely > resembles water/sewer/electric/gas service. That is, having 20 > people run fiber past your home when you're only going to buy from > one of them makes no economic sense. Indeed, we probably wouldn't > have both cable and DSL service if those were both to the home for > other reasons already. The copper pair from your house to the exchange isn't congested (at least, between you and other people), by definition. The fibre from your house to somewhere isn't congested, in the same way - although the 'somewhere' may be closer to you than the exchange. There's no reason to have competition here - but there's no reason to have a commercial entity trying to make a profit here either. Treat it like a real, basic utility, and run it on a cost-recovery basis, either directly by your local government entity, or by a dedicated organisation acting on their behalf. Whatever entity owns the local-loop sells access to competing service providers on an equal and transparent basis. Providers can then compete on level of network congestion, amongst other things, because they can directly control it in terms of how much backhaul they want to build from the exchange / FTTP street cab / whatever the aggregation point is against the volume of subscribers they sell off that aggregation point. For places which have it, this seems to work much better, or least break far less, than the alternatives (Openreach in the UK, Stokab in Stockholm being two I've dealt with). Exactly like electricity and gas - I only have one set of wires / pipes to my house, but there's a plethora of companies I can choose to buy energy services from. Regards, Tim.
Re: Addressing plan exercise for our IPv6 course
Jeroen Massar wrote: >> See my earlier comments on "upsell" and "control". While you >> have some ISPs starting from the mentality that gives us "accepting >> incoming connections is a chargeable extra", they're also going >> to be convinced that there's a revenue opportunity in segmenting >> customers who want N of some resource from those who want 2N, 4N, ... >> That the resource in question is, for all practical purposes, both >> free and infinite (cue someone with a 'tragedy of the commons' >> analysis) does not factor - if they want more, they must pay more! > > Ever thought about this tiny thing called BANDWIDTH USAGE? [snip] > Thus don't charge folks for the amount of IP addresses they have, that > is not what you get charged for by your transit/peers either. Apologies - again, my sarcasm doesn't travel well. I don't think selling IP addresses is a good idea - it's an idea I hit against and get annoyed by in the IPv4 world that I expect at least some ISPs to try and perpetuate into the IPv6 world. Regards, Tim.
Re: Addressing plan exercise for our IPv6 course
Owen DeLong wrote: > If you want to build a business based on upsell and control by trying > to convince users that they should give you extra money to provision > a resource that costs you virtually nothing, then more power to you. > > However, I think this will, in the end, be as popular as american > restaurants that charge for ice water. Sorry, I need to dial back on the cynicism / sarcasm a bit, it doesn't travel so well through the tubes - that's a rant about the attitudes I encounter, not my views! I *utterly* agree with you that trying to micro-manage the allocation size on a per-customer basis for high-volume residential / SOHO connections is a complete waste of resources. I equally believe that a number of ISPs operating in that market are going to try, not just one or two crazy outliers, based on the attitudes I touched on in my rant (which, again, *aren't* mine). Coming from an IPv4 business model that goes: Extra for a static IP Extra for more than one IP Extra for a contract that doesn't forbid incoming connections Extra for non-generic reverse DNS Extra for not blocking IPSec Extra for... I fully expect some ISPs to extend that into whatever parts of IPv6 they can measure and charge for. > Is probably going to be at a significant competitive disadvantage vs. > a model that says "You can have whatever address space you can > justify. We'll start you with 65,536 networks which we believe is way > more than enough for virtually any residential user. We don't charge > you anything for address space. We think charging people for integers > is illogical." I really hope you're right. I'd love to see the Internet opened back up again, for everyone. Regards, Tim.
Re: Addressing plan exercise for our IPv6 course
> Why waste valuable people's time to conserve nearly valueless > renewable resources? See my earlier comments on "upsell" and "control". While you have some ISPs starting from the mentality that gives us "accepting incoming connections is a chargeable extra", they're also going to be convinced that there's a revenue opportunity in segmenting customers who want N of some resource from those who want 2N, 4N, ... That the resource in question is, for all practical purposes, both free and infinite (cue someone with a 'tragedy of the commons' analysis) does not factor - if they want more, they must pay more! Regards, Tim.
Re: Addressing plan exercise for our IPv6 course
> I look at this as water under the bridge. Yep, it was complicated code > and now it works. I can run bittorrent just fine beyond an Apple > wireless router and I did nothing to make that work. Micro-torrent > just communicates with the router to make the port available. So, the security model here is that arbitrary untrusted applications, running on an arbitrary untrusted OS, selected by people who have no understanding of computer or network security are allowed to update the security policy on the perimeter device. I can see why those secure NAT boxes have *totally* stopped the Windows botnet problem in its tracks... > Of course, no disagreement there. The real challenge is going to be > education of customers so that they can actually configure a firewall > policy to protect their now-suddenly-addressable-on-the-Internet home > network. I would love to see how SOHO vendors are going to address this. Permit any outbound Permit any inbound established Deny any inbound Achieves essentially the same functionality as a NAT device without the annoying mangling of addresses. Vendors could then continue to offer the UPnP "request a hole" functionality that they do today, or tweak the labels on their "forward this port" web GUI to say "permit the port" instead. For end-users who want to carry on doing exactly what they do today, the changes required for both them and their CPE vendor are trivial. For end-users who are currently frustrated by NAT, they have their real, honest-to-goodness end-to-end Internet restored. Everybody wins, apart those with a vested interest in "upselling" to "business" connectivity plans, or those who would prefer that the Internet is TV on new technology, and that end-users remain good little eyeballs, dutifully paying for their Big Business Content. Regards, Tim.
Re: Nato warns of strike against cyber attackers
> Checklists come in handy in fact if many were followed (BCP > checklists, appropriate industry standard fw, system rules) > the net would be a cleaner place. Sensible checklists that actually improve matters, yes. The audit checklists I've often been subjected to, full of security theatre and things that are "accepted auditor wisdom" rather than contributing to the security of the network in any meaningful way, not so much. Regards, Tim.
Re: Nato warns of strike against cyber attackers
> I would expect that the increased awareness of network security that > resulted would pay dividends in business and home use of networks. I'd expect a lot of nice business for audit firms with the right government connections, and another checklist with a magic acronym that has everything to do with security theatre and nothing to do with either actual security or the reality of operating a network. But perhaps I'm jaded from dealing with current auditors. Regards, Tim.
Re: BT strike could affect internet and phone connections
> Internet and phone connections across Britain could go into meltdown > as BT workers threaten their first national strike for 23 years... > > ‘Many business and residential phonelines could go out of action, and > if broadband crashes then thousands and thousands of people will find > their internet goes down.’ > > http://www.metro.co.uk/news/828021-threat-of-bt-strike-could-affect-internet-and-phone-connections I get a lovely vision from that of a real old-style manual switchboard operator, frantically plugging internet connections together with patch cords as each SYN packet rings a little bell. Clearly BT engineers being on strike will stop broken things from being fixed[0]. I'm very unclear how it will cause things that are working today to suddenly "go into meltdown"... Regards, Tim. [0] As a residential customer, it's arguable how much of a change this is.
Re: Contacts re email deliverability problem to tmomail.net?
> That may be, but it would surprise me. The carriers still get paid > by virtue of charging the recipients for the SMSes, and in this > particular case cutting off this line of communication is leaving > money on the table, as email->SMS deliverability is desired yet > optional/secondary functionality of the app. Paying to *receive* SMS? And I thought the UK mobile industry was doing a good job of screwing its customers... In all seriousness, I wonder if they're using the same platform for their email gateways world-wide, and / or rate-limiting globally on the assumption that they're *not* making any money, as would be the case in many other locations? Especially if the Tmobile US operation is tech-driven (or otherwise) from the German parent. Regards, Tim.
Re: Connectivity to an IPv6-only site
> Which seems a bit far afield from reality to me. Yes, there are lots > of folks with IPv6 connectivity and v4-only recursive DNS servers. I > don't think ISPs will have problems setting aside a handful of IPv4 > addresses for authoritative DNS infrastructure to work around this > until v6 transport in recursive DNS servers is common enough. Assuming your ISP is providing your DNS. What if I, as a new start-up in the IPv4-exhausted world, want to buy pure bit-pipes from my ISP, and be responsible for *everything* further up the stack? I don't believe this is entirely uncommon. Regards, Tim.
Re: Router for Metro Ethernet
> All of those numbers are straight forwarding with nothing turned on > and 64 > byte packets. That way you get a nice idea of what the CPU can do. They're also, as ever, unidirectional, so you can immediately halve them if your question is "what size pipe can I connect this device to?" As a VPN managed CE, with QoS, BGP, a little bit of IPSLA etc, I'm seeing a practical limit of around 70Mb/s bidirectional out of the 3845. Regards, Tim.
Re: Router for Metro Ethernet
> Some caveats: > > 1. only the ME version supports MPLS, in case you want to overlay an > MPLS TE/VPN network on a Metro Ethernet Forum (MEF) ELAN raw Ethernet > service. > 2. If you are using IP multicast, make sure that the Metro Ethernet > provider supports PIM snooping, otherwise (S,G) directed multicast > packets will be flooded out all service provider ports that connect > to > your devices, emulating a 1993-style Ethernet hub. 3. Only "switch-style" QoS, not full-blown MQC. The 3750ME has two "router" ports which do mostly support MQC, but still have some limitations (e.g. traffic locally sourced from the device is not correctly classified / marked). Which is all kind of what you'd expect from a switch, but may be relevent if the original question was "which router?" Regards, Tim.
Re: what about 48 bits?
> This reminds of me of the failure-mode-within-a-failure-mode of 10b2 > with vaxstation2000's using vms's vaxcluster software. Unplugging the > 10b2 gave you a window of about 10 seconds before one by one every > vaxstation2000 would bugcheck. I was always rather astonished that > nobody at DEC either noticed it, or thought it was a very big deal > because the bug survived a long time. I thought that was just me. My first IT job was developing credit-card systems on VAXen. We had the office flood-wired with 10base2 in one long bus - at locations where there wasn't a PC yet, there was just a faceplace with two BNC connectors, and a tiny patch lead between them. To install a new PC, you had to have a length of co-ax long enough to go from the faceplate to the desk and back, with a T-piece in the middle. Installation involved whipping out the short patch lead and re-connecting both ends of the longer one before things elsewhere declared the network as broken and started shutting down somewhat ungracefully. This was best done as a two-man job, but we did get it down to quite an art. Nice to know after all this time that someone else was playing the same silly game... Regards, Tim.
Re: As the "NANOG Community" Moves to IPv6...
> P.S. Does anyone else think that perhaps "ipv3.com" == "Guillaume > FORTAINE"? It's spewing semi-coherent proposals for unworkable alternative addressing schemes. Sounds more like Jim Fleming to me. Perhaps we start comparing IPv3 to IPv8 and see if we get a reaction? ;) Regards, Tim.
Re: T1 aggregation and data center gateways
> Isn't that just CYA? Thank the lawyers and "corporate compliance >offices" and professional whiners. The obvious answer is that if your corporate email policy makes you look like an idiot, post to mailing lists from a personal email address that doesn't make you look like an idiot. This also spares the list from "out-of-office" messages from Exchange servers too stupid to refrain from sending such messages to mailing lists. Regards, Tim.
Re: Does Internet Speed Vary by Season?
> I read the article and the follow up posts and I wonder if we are all > using the same definition for "speed" here. The article seems to > imply you don't get 6 Mbps on your DSL line in summer because the > copper is hotter and it's harder to push electrons down the link. > That is clearly BS, the clock is ticking six million times per second, > period. Are you trying to say that the *actual* DSL speed, as synchronised between the modems at either end, is neither a) affected by the physical characteristics of the copper pair, nor b) variable? I agree the article is woolly between line-speed, throughput, goodput, congestion, etc, but to say that DSL line speed is in any way fixed in the same way that Ethernet or PDH / SDH lines are is contrary to every DSL platform I've worked with. (Also, 6Mb/s DSL doesn't equate to 6 million ticks per second in anything relating to pushing electrons onto the wire. Remember, it's modem technology, just faster - your baud rate is still much lower than your bps.) Regards, Tim.
Re: ServerBeach Name Server Outage?
> Is anyone else that uses ServerBeach hosting having issues with their name > servers (ns[12].geodns.net) failing to resolve their hostnames? I haven't seen any recent problems, although I have the geodns servers slaving from my server. Are you doing the same, or generating DNS directly on their NS (through the web front end)? Regards, Tim.
Re: DNS ed.gov translations
> ROTFL what an honour ;-), as we are in to weekend mood anyway I share > the reason for this. When I joined Colt my signature did look like this: > > --- > ___ ___ ___ ___ Ralf Weber t: +49 (0)69 56606 2780 > \C/ \O/ \L/ \T/ System Administrator > V V V VCOLT Telecom GmbHf: +49 (0)69 56606 6280 > IP Services e: r...@colt.net As did everyone's, I think - it's great that we had such an ASCII-art-friendly logo :) > That was used until our lawyers decided that as with real letters it > was their duty to design the fine print on email also. This lead to > what you see now below. I don't like it but am bound to use it. In the > signatur select box of my email program the signatur below is named > "r...@colt.net > violating RFC1855". I moved all my work-related mailing-list subscriptions to personal email when the legal departments started getting hold of .sigs. It seems pretty much impossible these days to post from a work address to any external email at all without looking like an idiot. (Of course, just removing the legal boilerplate doesn't, in itself, *prevent* me from looking an idiot, before anyone goes for the obvious...) Regards, Tim.
Re: Anyone notice strange announcements for 174.128.31.0/24
On Tue, January 13, 2009 8:57 pm, Joe Abley wrote: > The fact that I choose to stick 701 in an AS_PATH attribute on a > prefix I advertise in order to stop that prefix from propagating into > 701 is entirely my own business, and it's a practice which, although > apparently not commonplace, has been a well-known part of the IDTE > toolbox for many years. This does seem to be an interesting question. I'm AS X, I have no contractual relationship with AS Y, or indeed any informal peering relationship with them. All of my connectivity with AS Y is via at least one other AS. For whatever reason, technical, political, or pure whim, I don't want AS Y to receive any of my announcements. What's the correct tool to do this? Other than AS-PATH, I can't see a reliable way to do this currently. Lots of my peers or transits may have communities I can set to request that they don't announce my routes in particular regions, at particular peering points etc, but they almost certainly don't have one to restrict announcements to a specific AS. Do we need a set of well-known communities X:AS that can be recognised everywhere as "do not announce to AS"? Regards, Tim.
Re: InterCage, Inc. (NOT Atrivo)
On Thu, September 11, 2008 10:58 am, Eugeniu Patrascu wrote: > Why should an ISP provide proof of the good behavior of their clients ? > Or in your conuntry you're considered guilty until proven otherwise ? Conversely, and sticking close to the 'clean house' metaphor, if someone has a history of tramping mud into your carpets every previous time they've visited, is it unreasonable to ask them to present clean shoes before letting them into your house again? Regards, Tim.
Re: Creating demand for IPv6, and saving the planet
On Thu, October 4, 2007 6:49 am, Mike Leber wrote: > As the data at http://bgp.he.net/ipv6-progress-report.cgi shows for the > IPv6 and IPv4 nameserver tests, some of the time IPv6 connectivity is > *faster* than IPv4 connectivity (66 out of 264 test cases), because of > network topology differences due to different peering and transit > relationships between IPv4 and IPv6. Just as a odd data point, I see this for the only IPv6 test-bed I have available now, including tunnels. Home DSL (UK) -> EU tunnel broker -> IPv6 cloud -> US tunnel broker -> hosted server (California) is consistently 10-20ms lower than home -> IPv4 upstream -> IPv4 cloud -> server. Regards, Tim.
RE: Thoughts on best practice for naming router infrastructure in DNS
On Fri, June 29, 2007 4:35 pm, Neil J. McRae wrote: > I remember in the past an excellent system using Sesame Street characters > names. Doesn't scale though :( Hence the rapid emergence of southpark-naming-draft-001.txt, flintstones-naming-draft-001.txt. Not to mention the grover / super-grover / new-grover / new-super-grover incident. Regards, Tim.