On 03/11/2013 07:09 PM, Kevin Chadwick wrote: >> No, there was simply no useful result that came up. Incidentally, >> both links you provide *did* come up...but I dismissed them >> because I couldn't imagine anyone using them as a reference except >> in trying to deride Henning Brauer. >> >>> >>> http://marc.info/?l=openbsd-misc&m=129666298029771&w=2 >> >> He goes from advocating NAT444 to a spew of pejoratives about >> something. NAT444 is one of the nastiest, user-disempowering >> things to hit the Internet to date. The rest of this email is him >> bitching about having to parse CIDR notation. >> > > How disengenuous. He certainly doesn't.
Advocacy of NAT444: " who sez that your made up isp has to hand out network-wide unique IPs " to his customers? Bitching about having to parse CIDR: " look at the oh so bright future yourself, look at the code required to " deal with that misdesigned piece of shit. " did i just say "designed"? sorry. it's obvious that nothing remotely " related to design was involved. > Did you miss the sarcasm. Pretty sure I didn't. > The only reason he advocates is because others using it allow him to > keep running ipv4 pure networks. That's some useful context. > > After that I'm sure you can forgive me if I note him to have > absolutely no reason to be biased and give him a bit more credit and > take his experience of writing one of the best and widely used > interrupt driven firewalls and so code to deal with ipv6, helping > get the netqmail patch sorted and runs his own decent sized network So he's a smart guy with a decent amount of experience. That doesn't make him right. Let me tell you about a similar guy I know. Let's start with my biological father. He started programming as a kid when he got his hands on a 6802 evaluation board, wrote his own operating systems, had a hand in designing the bar code format the US postal service uses for sorting and routing, and provided the local municipality with its first remote electronic monitoring of its water tower. He was one of the first people to jump into Windows NT, with Windows NT 3.51, as he understood the value the NT kernel offered over the DOS-based versions of Windows. He was quite a guy. But he wasn't always right. He *hated* the transition from MFM to IDE drives, as he wasn't able to perform the kinds of diagnostics he wanted to. Once he latched on to Windows NT, he never let go of Microsoft for a second. He didn't see a point to POSIX, UNIX or Linux, and I was never able to get him interested. With the exception of things written or distributed by Microsoft, he never used third-party tools, and had to write everything from the ground-up the way he wanted it. When given specs by other people, he would hand them a product that was what he thought they needed, not what they asked for. He further never felt the need to work with or learn from anyone else in his field. He's brilliant. Quite literally an accomplished genius...but once he got it in his head that he knew what needed to be known, there wasn't room for much new, and there wasn't room for much new. I've tried working with him in architecting web services, and I couldn't. He rejected the idea of using any existing data serialization or transport format, because it wouldn't be as efficient as something he could write. His system architecture relied on a central synchronous component, but the goal of the system was supposed to support scaling. (It couldn't.) Just because he was amazing and awesome among his contemporaries in the past doesn't say anything about his relative skill and knowledge in the present. > over yours who I am sure is genuine but could well be partial to > ipv6 because as you say you teach setting up ipv6 networks. You need to analyze things on their technical merits, not just on who says them. I won't ask someone to use IPv6 where it's inappropriate. I do believe in pragmatic solutions (systemd and merged /usr notwithstanding ;) ). I don't generally hold for Ludditism. If someone wants to actively reject a technology, I'd like to at least make sure it's for the right reasons. > > http://marc.info/?l=openbsd-misc&m=124536321827774&w=2 True enough. And since we're there, it's critical that people learn how to handle their problems. > >>> >>> http://marc.info/?l=openbsd-misc&m=135325826302392&w=2 >>> >> >> This email has absolutely no technical content whatsoever. > > Did you not follow the threads? No. If you want me to read something, you need to point at what I should read. You didn't indicate I should be reading a thread (as opposed to an individual message...) > > I couldn't find the juicier threads about client troubles due to > added complexity but here's some relevent ones and many by very > competent devs. (and if I'm honest who tend to shadow every other > list I've come across so far as long as you are not timid and can > take a hit, though Gentoo is up there). > > http://marc.info/?l=openbsd-misc&m=128822984018595&w=2 Re: ARP -- Sure, they don't like ND. That's fine; we covered that earlier. Re: IPv6 routing -- That's, er, pretty comfortably solved. For a *long* time. About the only real problem right now is the spat between a couple of the tier 1 backbones...but that's not a problem with IPv6 per se. Re: Sockaddr size and alignment...I don't see the problem; alignment and padding is de jure in software development these days, if only for performance reasons. That said, > http://marc.info/?l=openbsd-misc&m=135325736302228&w=2 Peltola is making arguments I've never heard discussed in practice, and Brauer is rightfully reading him the riot act. > http://marc.info/?l=openbsd-misc&m=128825496411711&w=2 Honestly, if they set up a donation drive, I'm willing to bet they could have pulled together enough money to get in. However, they either didn't think of this, didn't think they could pull together enough money, or didn't really want to have to associate with the committees they're so angry with. (I think it's most likely a combination of those last two.) > http://marc.info/?l=openbsd-misc&m=129665675320651&w=2 Here, Brauer is advocating something that's not really possible (AFAIK) per ARIN, APNIC, LAPNIC and RIPE policies. It'd start with "Hey, APNIC, we see you haven't been assigning many netblocks. We're going to take a few of those back." For ARIN, LAPNIC and RIPE, it'd be "Hey, entity that paid for a perpetual license to that net block. We don't think you're using your address space efficiently enough, so we're going to take some of those blocks back." That'd go over *real* well. Start with holding back technological development on Africa, continue with making it uncertain whether or not one gets to keep their IP range after they've paid for it. I can just picture all the rule lawyering and metric gaming as IP block holders examine qualification rules and contort their networks to behave less efficiently (but more efficiently per the qual rules!) so things hold together. > http://marc.info/?l=openbsd-misc&m=135111069427240&w=2 " Ha ha ha ha, this will work for a single host but how will you manage " multiple ones. Bonus question, how do you think the host router with " no knowledge of the underlying network topology will choose a route? To start with, RAs include route preference metrics as well as route packing; the network router can not only declare the prefix it's responsible for, but it can also announce that it has more-specific routes for other address ranges, too. I use this at home, where I've given my wired network and my wireless network different /64s out of the same /48. The RA for my wired network also announces that the router has a specific route for the /64 for the wireless network, and the RA for the wireless network announces that the router has a specific route for the /64 for the wired network. Basically, the host router has as much topology knowledge as the router's RA is configured to include. Claudo goes on to assert that SCTP is over-engineered. I guess that might be true if you believe that separate UDP and TCP streams are sufficient...but I've had to cope with scenarios where they aren't. SCTP solves problems that exist in the real world. He then goes on to assert that end hosts can't handle the truth of the network around them. I don't buy it... > http://marc.info/?l=openbsd-misc&m=135110983026959&w=2 RIPE's allocation policy was screwy. OK, sure. Not sure what that has to do with anything. > http://marc.info/?l=openbsd-misc&m=135110833526455&w=2 " As someone working for a 'Carrier' vendor - I can tell you straight " up that LSN(Large Scale) or CGN(Carrier Grad) NAT are big sell points " (i.e customers are asking for them). So, as a guy who sells NAT solutions, he can say that customers are asking for NAT solutions. (Well, I should hope so for logic's sake, or they wouldn't be customers...) The rest of the email is spot on. NAT64 is an excellent transition mechanism. But it's exactly that: A *transition* mechanism. > http://marc.info/?l=openbsd-misc&m=135110805826344&w=2 Peltola is arguing that NAT66 is possible (it is). Theo is dismissing Peltola, saying that in IPv6, applications should handle address changes. (They should.) Both are correct. Theo goes on to say that not everything roams. (He's correct.) > http://marc.info/?l=openbsd-misc&m=135110703125929&w=2 I don't understand the network context Theo is describing. It sounds like he's describing a scenario where a network has two IPv4 ISPs who allow same IP range (controlled by the network admin, presumably PI space), but where that same network has two IPv6 ISPs who each demand the network admin only send traffic out using IPv6 prefixes they're delegating. This is a retarded arrangement; the ISPs should offer parity between IPv4 and IPv6, meaning they should allow PI space in both cases. Even if you assume Theo is talking about IPv4 NAT here, IPv4 NAT isn't going to solve the problem. When your NATting router has to switch from one ISP to the other, it'd have to switch from one IPv4 IP to another, resulting in the exact same scenario he's claiming IPv6 would uniquely require him to solve. Finally, if you assume that Theo is talking about some kind of connection to another host that doesn't require ISP routing (so it might be via a VPN tunnel or on the local network), then it almost makes sense; the IPv4 context would assume you're in RFC1918 space thanks to your NAT, so your IPv4 addresses wouldn't change as your upstream network connection changes. Meanwhile, your IPv6 context would change, because one of your two prefixes would drop out, and anything using it would fail. Except Theo's solution to this is also silly. In this final scenario, there's already a solution at hand: ULA addresses. They're IPv6's equivalent to IPv4's RFC1918 space, and it's generally suggested that you use ULA on your internal network in order to provide stable addressing within your network to services on your network--which neatly (and by design) avoids the problem Theo claims he's forced to solve. Remember that in IPv6, you can (and will) have multiple IP addresses with different prefixes attached to each NIC. At the very least, you'll have a link-local IPv6 address. You will probably also have a global-scope IPv6 address--possibly many. You may have an address derived from a ULA prefix--possibly many such prefixes. Your network can be as complex or as simple as you choose to make it, but the ULA address space is there to solve this kind of problem. > http://marc.info/?l=openbsd-misc&m=135110533625263&w=2 I expect PI space will become more attainable; it simply must. Other than that, I don't agree with anything Simon or Theo say here. > http://marc.info/?l=openbsd-misc&m=124537193506202&w=2 Again, no technical content...
signature.asc
Description: OpenPGP digital signature
