Re: [Bulk] Re: [gentoo-user] /etc/hosts include file?

[Michael Mol]

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...