[gentoo-user] /etc/hosts include file?

[gentoo-user] /etc/hosts include file?

[Alan McKinnon]

Anyone know if there's a way to get /etc/hosts to support the notion of
an include file? I did my homework and found nothing, maybe someone else
knows more.

I really do need this, I have an app that discovers things on the
network and knows their address. This makes it's automated way into DNS
but takes a few days, and another app needs to use the fqdn right now.
So /etc/hosts is the way to go for the interim three days.

I've worked around it by creating /etc/hosts.d/ containing a header and
a data file. cat the two and redirect to /etc/hosts.d/hosts and the real
hosts file is a symlink to that. It's a sub-directory as none of these
apps run as root and only root can modiy the real hosts file.

This works well enough, but a supported include mechanism would make
life so much simpler, not to mention easier for my colleagues to
understand what the blazes I set up :-)



-- 
Alan McKinnon
alan.mckinnon@gmail.com

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

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]

On Mar 7, 2013 5:28 PM, "Alan McKinnon" <alan.mckinnon@gmail.com> wrote:
>
> Anyone know if there's a way to get /etc/hosts to support the notion of
> an include file? I did my homework and found nothing, maybe someone else
> knows more.
>
> I really do need this, I have an app that discovers things on the
> network and knows their address. This makes it's automated way into DNS
> but takes a few days, and another app needs to use the fqdn right now.
> So /etc/hosts is the way to go for the interim three days.
>
> I've worked around it by creating /etc/hosts.d/ containing a header and
> a data file. cat the two and redirect to /etc/hosts.d/hosts and the real
> hosts file is a symlink to that. It's a sub-directory as none of these
> apps run as root and only root can modiy the real hosts file.
>
> This works well enough, but a supported include mechanism would make
> life so much simpler, not to mention easier for my colleagues to
> understand what the blazes I set up :-)
>
>
>
> --
> Alan McKinnon
> alan.mckinnon@gmail.com
>
>
>

See resolv.conf and nsswitch.conf

More details later...but nsswitch, at least, is how one can mix hosts, DNS,
NIS and winbind on the same box...

[-- Attachment #2: Type: text/html, Size: 1562 bytes --]

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

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 1984 bytes --]

On 03/07/2013 05:24 PM, Alan McKinnon wrote:
> Anyone know if there's a way to get /etc/hosts to support the notion of
> an include file? I did my homework and found nothing, maybe someone else
> knows more.
> 
> I really do need this, I have an app that discovers things on the
> network and knows their address. This makes it's automated way into DNS
> but takes a few days, and another app needs to use the fqdn right now.
> So /etc/hosts is the way to go for the interim three days.
> 
> I've worked around it by creating /etc/hosts.d/ containing a header and
> a data file. cat the two and redirect to /etc/hosts.d/hosts and the real
> hosts file is a symlink to that. It's a sub-directory as none of these
> apps run as root and only root can modiy the real hosts file.
> 
> This works well enough, but a supported include mechanism would make
> life so much simpler, not to mention easier for my colleagues to
> understand what the blazes I set up :-)

No, there's not an "include" directive.

There are, however, two other ways to get hostnames recognized.

The first is /etc/resolv.conf . You can point your host at a local DNS
server which is aware of the discovered hosts, and which forwards the
rest of the queries. (This is how Samba 4's internal DNS server
operates; anything it knows, it responds to. Everything else, it forwards.)

Read the manpage for resolv.conf...there's a lot of stuff in there
you'll want to know as you start coping with IPv6. (And some useful
stuff if you want to favor a particular IP range...)

The second is /etc/nsswitch.conf . nsswitch.conf is how you inject
samba-discovered, NIS-offered -- or whatever provider you care to inject
-- hostname databases into the system resolver. You could have it query
your provided database first, moving on to other sources if your
provided database doesn't have what you're looking for. (I'm actually
kinda surprised avahi doesn't come with an nss plugin...)



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Alan McKinnon]

On 08/03/2013 02:29, Michael Mol wrote:
> On 03/07/2013 05:24 PM, Alan McKinnon wrote:
>> Anyone know if there's a way to get /etc/hosts to support the notion of
>> an include file? I did my homework and found nothing, maybe someone else
>> knows more.
>>
>> I really do need this, I have an app that discovers things on the
>> network and knows their address. This makes it's automated way into DNS
>> but takes a few days, and another app needs to use the fqdn right now.
>> So /etc/hosts is the way to go for the interim three days.
>>
>> I've worked around it by creating /etc/hosts.d/ containing a header and
>> a data file. cat the two and redirect to /etc/hosts.d/hosts and the real
>> hosts file is a symlink to that. It's a sub-directory as none of these
>> apps run as root and only root can modiy the real hosts file.
>>
>> This works well enough, but a supported include mechanism would make
>> life so much simpler, not to mention easier for my colleagues to
>> understand what the blazes I set up :-)
> 
> No, there's not an "include" directive.
> 
> There are, however, two other ways to get hostnames recognized.
> 
> The first is /etc/resolv.conf . You can point your host at a local DNS
> server which is aware of the discovered hosts, and which forwards the
> rest of the queries. (This is how Samba 4's internal DNS server
> operates; anything it knows, it responds to. Everything else, it forwards.)
> 
> Read the manpage for resolv.conf...there's a lot of stuff in there
> you'll want to know as you start coping with IPv6. (And some useful
> stuff if you want to favor a particular IP range...)

And the day started off so well. Then you had to come along and mention
IPv6.... :-)

IPv6 is wonderfully easy to use client-side and reasonably easy to plug
into an existing network (the routers mostly know what to do already).
The fun starts when you need to write an app that tracks and does range
allocations at ISP scale, all while keeping the PTRs in line too. Sadly
for me, my team works in that area and such a magic app is one of our
deliverables

One day when I've climbed down off the walls and my fingernails have
grown back, I might be up to relating what it is taking to get that
done.... :-)

> 
> The second is /etc/nsswitch.conf . nsswitch.conf is how you inject
> samba-discovered, NIS-offered -- or whatever provider you care to inject
> -- hostname databases into the system resolver. You could have it query
> your provided database first, moving on to other sources if your
> provided database doesn't have what you're looking for. (I'm actually
> kinda surprised avahi doesn't come with an nss plugin...)

One day I should read nsswitch's man page completely. I never needed to
know more than "dns files" for the hosts directives and that shadow does
user. All those other lookup schemes are things I never use.




-- 
Alan McKinnon
alan.mckinnon@gmail.com

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

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 3605 bytes --]

On 03/08/2013 03:32 AM, Alan McKinnon wrote:
> On 08/03/2013 02:29, Michael Mol wrote:
>> On 03/07/2013 05:24 PM, Alan McKinnon wrote:
>>> Anyone know if there's a way to get /etc/hosts to support the notion of
>>> an include file? I did my homework and found nothing, maybe someone else
>>> knows more.
>>>
>>> I really do need this, I have an app that discovers things on the
>>> network and knows their address. This makes it's automated way into DNS
>>> but takes a few days, and another app needs to use the fqdn right now.
>>> So /etc/hosts is the way to go for the interim three days.
>>>
>>> I've worked around it by creating /etc/hosts.d/ containing a header and
>>> a data file. cat the two and redirect to /etc/hosts.d/hosts and the real
>>> hosts file is a symlink to that. It's a sub-directory as none of these
>>> apps run as root and only root can modiy the real hosts file.
>>>
>>> This works well enough, but a supported include mechanism would make
>>> life so much simpler, not to mention easier for my colleagues to
>>> understand what the blazes I set up :-)
>>
>> No, there's not an "include" directive.
>>
>> There are, however, two other ways to get hostnames recognized.
>>
>> The first is /etc/resolv.conf . You can point your host at a local DNS
>> server which is aware of the discovered hosts, and which forwards the
>> rest of the queries. (This is how Samba 4's internal DNS server
>> operates; anything it knows, it responds to. Everything else, it forwards.)
>>
>> Read the manpage for resolv.conf...there's a lot of stuff in there
>> you'll want to know as you start coping with IPv6. (And some useful
>> stuff if you want to favor a particular IP range...)
> 
> And the day started off so well. Then you had to come along and mention
> IPv6.... :-)
> 
> IPv6 is wonderfully easy to use client-side and reasonably easy to plug
> into an existing network (the routers mostly know what to do already).
> The fun starts when you need to write an app that tracks and does range
> allocations at ISP scale, all while keeping the PTRs in line too. Sadly
> for me, my team works in that area and such a magic app is one of our
> deliverables

My mouth is watering...

> 
> One day when I've climbed down off the walls and my fingernails have
> grown back, I might be up to relating what it is taking to get that
> done.... :-)

I don't suppose you knew I'm a huge IPv6 advocate, and travel around my
state giving free training sessions...

I would absolutely love to hear about the problems you're facing.
Further, I'd love to help you get past them...and can put you in touch
with experts who might also be able to help.


> 
>>
>> The second is /etc/nsswitch.conf . nsswitch.conf is how you inject
>> samba-discovered, NIS-offered -- or whatever provider you care to inject
>> -- hostname databases into the system resolver. You could have it query
>> your provided database first, moving on to other sources if your
>> provided database doesn't have what you're looking for. (I'm actually
>> kinda surprised avahi doesn't come with an nss plugin...)
> 
> One day I should read nsswitch's man page completely. I never needed to
> know more than "dns files" for the hosts directives and that shadow does
> user. All those other lookup schemes are things I never use.

I've never mucked with NIS, but I muck with samba from time to time.

If you're already in a developer context, I'd suggest writing an NSS
plugin the system resolver can check on. That's the angle I'd take in
your circumstance.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Alan McKinnon]

On 08/03/2013 15:40, Michael Mol wrote:
>> IPv6 is wonderfully easy to use client-side and reasonably easy to plug
>> > into an existing network (the routers mostly know what to do already).
>> > The fun starts when you need to write an app that tracks and does range
>> > allocations at ISP scale, all while keeping the PTRs in line too. Sadly
>> > for me, my team works in that area and such a magic app is one of our
>> > deliverables
> My mouth is watering...
> 
>> > 
>> > One day when I've climbed down off the walls and my fingernails have
>> > grown back, I might be up to relating what it is taking to get that
>> > done.... :-)
> I don't suppose you knew I'm a huge IPv6 advocate, and travel around my
> state giving free training sessions...
> 
> I would absolutely love to hear about the problems you're facing.
> Further, I'd love to help you get past them...and can put you in touch
> with experts who might also be able to help.
> 
> 

I too am a huge fan of IPv6. It will all at once fix two things:

1. The craziness of trying to conserve IPv4 space
2. NAT. Finally, a good solid techical reason to make NAT just go away
and stay away. Permanently. Forever.

Without getting into huge amounts of boring detail on the list, the
major problem is finding software that can fulfil our backend needs.

We're an ISP and we sell address space. We also allocate space
internally to our own customers and need to keep accurate records as to
who has what. There are some good packages on the market that function
as a DNS backend where you enter the relevant IPv6 data and it takes
care of the forward and reverse entries. We need something a bit more
than that, we need the software to do block allocation. So it must not
be a mere record of stuff, it must be the authoritative source of
reference for that stuff, and it must understand the people involved and
their roles (what they may allocate etc).

The best package we found so far is one from Cricket Liu's company (I
forget the app name for the moment, it was a while ago) but it doesn't
do allocation and the backend db isn't really designed for that.

And I nearly forgot to mention, I also need magic post-allocation hooks
in the code. I'm determined to get to a point where unallocated blocks
will be black-holed by the core routers. They must only start passing
the traffic once a properly assigned block has been allocated and
recorded as such. If you ever worked at ISP level, you will immediately
understand why that is rather important :-)

Speak later.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

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

[Kevin Chadwick]

> 1. The craziness of trying to conserve IPv4 space
> 2. NAT. Finally, a good solid techical reason to make NAT just go away
> and stay away. Permanently. Forever.

It's a great shame that isn't all it fixed (ipv5), then your job
wouldn't have been so hard and there wouldn't be any reason for many of
us to cling to ipv4 of which there are many strong reasons that are far
far worse than NAT.


-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

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

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

On 03/08/2013 02:50 PM, Kevin Chadwick wrote:
>> 1. The craziness of trying to conserve IPv4 space
>> 2. NAT. Finally, a good solid techical reason to make NAT just go away
>> and stay away. Permanently. Forever.
> 
> It's a great shame that isn't all it fixed (ipv5), then your job
> wouldn't have been so hard and there wouldn't be any reason for many of
> us to cling to ipv4 of which there are many strong reasons that are far
> far worse than NAT.
> 
> 

IPv5 never really existed.

http://www.oreillynet.com/onlamp/blog/2003/06/what_ever_happened_to_ipv5.html


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Kevin Chadwick]

> >> 1. The craziness of trying to conserve IPv4 space
> >> 2. NAT. Finally, a good solid techical reason to make NAT just go away
> >> and stay away. Permanently. Forever.  
> > 
> > It's a great shame that isn't all it fixed (ipv5), then your job
> > wouldn't have been so hard and there wouldn't be any reason for many of
> > us to cling to ipv4 of which there are many strong reasons that are far
> > far worse than NAT.
> > 
> >   
> 
> IPv5 never really existed.
> 
> http://www.oreillynet.com/onlamp/blog/2003/06/what_ever_happened_to_ipv5.html

First I've heard of ST or an actual ipv5 but sounds like they had
dropped a layer. Having options like tcp or udp is a good thing.

What would have been best, could have been done years ago and not cost
lots of money and even more in security breaches and what I meant by
ipv5 and would still be better to switch to even today with everyone
being happy to switch to it is simply ipv4 with more bits for address
space.

If I got an ISP who only offers me IPV6 I would drop the ISP before the
IPV4!

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

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

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]

On Mar 9, 2013 4:51 AM, "Kevin Chadwick" <ma1l1ists@yahoo.co.uk> wrote:
>
> > >> 1. The craziness of trying to conserve IPv4 space
> > >> 2. NAT. Finally, a good solid techical reason to make NAT just go
away
> > >> and stay away. Permanently. Forever.
> > >
> > > It's a great shame that isn't all it fixed (ipv5), then your job
> > > wouldn't have been so hard and there wouldn't be any reason for many
of
> > > us to cling to ipv4 of which there are many strong reasons that are
far
> > > far worse than NAT.
> > >
> > >
> >
> > IPv5 never really existed.
> >
> >
http://www.oreillynet.com/onlamp/blog/2003/06/what_ever_happened_to_ipv5.html
>
> First I've heard of ST or an actual ipv5 but sounds like they had
> dropped a layer. Having options like tcp or udp is a good thing.
>
> What would have been best, could have been done years ago and not cost
> lots of money and even more in security breaches and what I meant by
> ipv5 and would still be better to switch to even today with everyone
> being happy to switch to it is simply ipv4 with more bits for address
> space.
>
> If I got an ISP who only offers me IPV6 I would drop the ISP before the
> IPV4!
>

Unfortunately, your logic is flawed.

Where would you put the additional bits of address?

That would involve rewriting the IP Header.

And while we're at it, why not *totally* remake IP based on decades of
observation & experience?

Hence, IPv6.

Rgds,
--

[-- Attachment #2: Type: text/html, Size: 1937 bytes --]

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

[Kevin Chadwick]

> Unfortunately, your logic is flawed.
> 
> Where would you put the additional bits of address?
> 
> That would involve rewriting the IP Header.
> 

Your assumption that I do not know that is flawed. I did a review of
ipv6 before it was released and determined ipv4 to be superior then.
That was before I was shown some of the bad sides more recently.

> And while we're at it, why not *totally* remake IP based on decades of
> observation & experience?
> 

Who's observations and who's experience. Not everyones that's for damn
sure.

> Hence, IPv6.

Lookup ipvshit

I'll give you a hint.

The guy who wrote most of the pf firewall that MAC OSX now uses as well
as QNX, the latest version originating from OpenBSD and being far better
than iptables has bought up lots of ipv4 just to stay away from ipvshit.

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

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

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]

On 03/08/2013 07:50 PM, Kevin Chadwick wrote:
>> Unfortunately, your logic is flawed.
>>
>> Where would you put the additional bits of address?
>>
>> That would involve rewriting the IP Header.
>>
> 
> Your assumption that I do not know that is flawed. I did a review of
> ipv6 before it was released and determined ipv4 to be superior then.
> That was before I was shown some of the bad sides more recently.
> 
>> And while we're at it, why not *totally* remake IP based on decades of
>> observation & experience?
>>
> 
> Who's observations and who's experience. Not everyones that's for damn
> sure.

This is why the IETF exists, to allow vendors and engineers with field
knowledge to argue and debate until they come up with something that
most of them can agree on. IPv6 is what came out of that process.

I'm not going to say IPv6 doesn't have flaws...but it's certainly a lot
better than IPv4, and features it adds (even beyond address space
expansion) are very nice.

> 
>> Hence, IPv6.
> 
> Lookup ipvshit
> 
> I'll give you a hint.
> 
> The guy who wrote most of the pf firewall that MAC OSX now uses as well
> as QNX, the latest version originating from OpenBSD and being far better
> than iptables has bought up lots of ipv4 just to stay away from ipvshit.
> 

Tried searching for it. You're going to have to provide some useful
direct reference, because a basic search wasn't very illuminating.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Kevin Chadwick]

> > 
> > Lookup ipvshit
> > 
> > I'll give you a hint.
> > 
> > The guy who wrote most of the pf firewall that MAC OSX now uses as well
> > as QNX, the latest version originating from OpenBSD and being far better
> > than iptables has bought up lots of ipv4 just to stay away from ipvshit.
> >   
> 
> Tried searching for it. You're going to have to provide some useful
> direct reference, because a basic search wasn't very illuminating.

Perhaps Google doesn't approve of swear words?!

http://marc.info/?l=openbsd-misc&m=129666298029771&w=2

http://marc.info/?l=openbsd-misc&m=135325826302392&w=2

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

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

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]

On 03/09/2013 07:53 AM, Kevin Chadwick wrote:
>>>
>>> Lookup ipvshit
>>>
>>> I'll give you a hint.
>>>
>>> The guy who wrote most of the pf firewall that MAC OSX now uses as well
>>> as QNX, the latest version originating from OpenBSD and being far better
>>> than iptables has bought up lots of ipv4 just to stay away from ipvshit.
>>>   
>>
>> Tried searching for it. You're going to have to provide some useful
>> direct reference, because a basic search wasn't very illuminating.
> 
> Perhaps Google doesn't approve of swear words?!

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.

> 
> http://marc.info/?l=openbsd-misc&m=135325826302392&w=2
> 

This email has absolutely no technical content whatsoever.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Kevin Chadwick]

> 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. Did you miss the sarcasm. The
only reason he advocates is because others using it allow him to keep
running ipv4 pure networks.

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

   http://marc.info/?l=openbsd-misc&m=124536321827774&w=2

> > 
> > http://marc.info/?l=openbsd-misc&m=135325826302392&w=2
> >   
> 
> This email has absolutely no technical content whatsoever.

Did you not follow the threads?

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
  http://marc.info/?l=openbsd-misc&m=135325736302228&w=2
  http://marc.info/?l=openbsd-misc&m=128825496411711&w=2
  http://marc.info/?l=openbsd-misc&m=129665675320651&w=2
  http://marc.info/?l=openbsd-misc&m=135111069427240&w=2
  http://marc.info/?l=openbsd-misc&m=135110983026959&w=2
  http://marc.info/?l=openbsd-misc&m=135110833526455&w=2
  http://marc.info/?l=openbsd-misc&m=135110805826344&w=2
  http://marc.info/?l=openbsd-misc&m=135110703125929&w=2
  http://marc.info/?l=openbsd-misc&m=135110533625263&w=2
  http://marc.info/?l=openbsd-misc&m=124537193506202&w=2


-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

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

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 12151 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Walter Dnes]

On Fri, Mar 08, 2013 at 09:49:23PM +0000, Kevin Chadwick wrote

> What would have been best, could have been done years ago and not cost
> lots of money and even more in security breaches and what I meant by
> ipv5 and would still be better to switch to even today with everyone
> being happy to switch to it is simply ipv4 with more bits for address
> space.

  This should be FAQ entry zero for the IPV6 FAQ... *NO* you can *NOT*
add more bits to IPV4, and still have it backwards compatable.  It won't
work... period... end of story.  Every piece of hardware and software
that deals with IPV4 has the concept of 32 bits *HARD-CODED* into it.
Switching over to IPV4-extended would be just as painfull as switching
over to IPV6.

  We will be running out of IPV4 address space shortly so we do need to
upgrade.  Having said that, I don't understand all the hate for NAT.  At
the risk of being called an elitist, I'll say that 95% of average
internet users have no business running servers; heck many of them can't
even keep *CLIENTS* properly secured.  If IPV6-NAT in my home causes me
any problem, that's my problem.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 1788 bytes --]

On 03/08/2013 07:13 PM, Walter Dnes wrote:
> On Fri, Mar 08, 2013 at 09:49:23PM +0000, Kevin Chadwick wrote
> 
>> What would have been best, could have been done years ago and not cost
>> lots of money and even more in security breaches and what I meant by
>> ipv5 and would still be better to switch to even today with everyone
>> being happy to switch to it is simply ipv4 with more bits for address
>> space.
> 
>   This should be FAQ entry zero for the IPV6 FAQ... *NO* you can *NOT*
> add more bits to IPV4, and still have it backwards compatable.  It won't
> work... period... end of story.  Every piece of hardware and software
> that deals with IPV4 has the concept of 32 bits *HARD-CODED* into it.
> Switching over to IPV4-extended would be just as painfull as switching
> over to IPV6.
> 
>   We will be running out of IPV4 address space shortly so we do need to
> upgrade.  Having said that, I don't understand all the hate for NAT.  At
> the risk of being called an elitist, I'll say that 95% of average
> internet users have no business running servers; heck many of them can't
> even keep *CLIENTS* properly secured.  If IPV6-NAT in my home causes me
> any problem, that's my problem.
> 

The trouble with NAT is that it destroys peer-to-peer protocols. The
first was FTP in Active mode. SIP has been heavily damaged as well.
Anyone who's used IRC is familiar with the problems NAT introduces to
DCC. Anyone who's ever played video games online, or who's tried hosting
a Teamspeak or Ventrillo server, has had NAT get in their way as well.

Seriously, why should my voice packets have to travel across three or
more states in order to bounce through Google Voice servers, if I'm
talking to my wife on her laptop in the next city over?




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Walter Dnes]

On Fri, Mar 08, 2013 at 07:41:13PM -0500, Michael Mol wrote

> The trouble with NAT is that it destroys peer-to-peer protocols. The
> first was FTP in Active mode.

  In its day, it was OK.  Nowadays, we use passive mode.  What's the
problem?

> SIP has been heavily damaged as well.  Anyone who's used IRC is
> familiar with the problems NAT introduces to DCC.

  Every ADSL router-modem I've run into recently has port-forwarding.

> Anyone who's ever played video games online,...

  A *CLIENT* that can't operate from behind NAT is totally brain-dead.

> or who's tried hosting a Teamspeak or Ventrillo server, has had NAT
> get in their way as well.

  Port-forwarding.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[Michael Orlitzky]

On 03/09/2013 08:42 PM, Walter Dnes wrote:
> On Fri, Mar 08, 2013 at 07:41:13PM -0500, Michael Mol wrote
> 
>> The trouble with NAT is that it destroys peer-to-peer protocols. The
>> first was FTP in Active mode.
> 
>   In its day, it was OK.  Nowadays, we use passive mode.  What's the
> problem?
> 

It also doesn't work under NAT, it's just broken in the other direction.


>> SIP has been heavily damaged as well.  Anyone who's used IRC is
>> familiar with the problems NAT introduces to DCC.
> 
>   Every ADSL router-modem I've run into recently has port-forwarding.
> 
>> Anyone who's ever played video games online,...
> 
>   A *CLIENT* that can't operate from behind NAT is totally brain-dead.
> 

But you must have one non-NATed "server" for anything to work. I assume
that's what was meant by "it destroys peer-to-peer protocols." You have
to draw an arbitrary distinction between machines that work together,
"servers," and ones that don't, "clients."

The problem will become more and more apparent as ipv4 space dries up
and everyone becomes a client. Although ISPs will be more than happy to
sell you a useful connection, for a premium.

Un-NATed addresses are like, type-O blood. Imagine how much better off
we'd be if we could get everyone to switch their blood to type-O. Might
be less painful than the ipv6 transition, too =)


>> or who's tried hosting a Teamspeak or Ventrillo server, has had NAT
>> get in their way as well.
> 
>   Port-forwarding.
> 

Port forwarding can work, but only for one host when the ports are
standardized. You can't forward e.g. port 443 to two hosts, so only one
host behind the NAT can be accessible on 443.

If you're using your NAT as a firewall for one box, then who cares. But
you can't put more than one machine behind it and have everything still
work.

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

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 2266 bytes --]

On 03/09/2013 11:59 PM, Michael Orlitzky wrote:
> On 03/09/2013 08:42 PM, Walter Dnes wrote:
>> On Fri, Mar 08, 2013 at 07:41:13PM -0500, Michael Mol wrote
>>
>>> The trouble with NAT is that it destroys peer-to-peer protocols. The
>>> first was FTP in Active mode.
>>
>>   In its day, it was OK.  Nowadays, we use passive mode.  What's the
>> problem?
>>
> 
> It also doesn't work under NAT, it's just broken in the other direction.
> 
> 
>>> SIP has been heavily damaged as well.  Anyone who's used IRC is
>>> familiar with the problems NAT introduces to DCC.
>>
>>   Every ADSL router-modem I've run into recently has port-forwarding.
>>
>>> Anyone who's ever played video games online,...
>>
>>   A *CLIENT* that can't operate from behind NAT is totally brain-dead.
>>
> 
> But you must have one non-NATed "server" for anything to work. I assume
> that's what was meant by "it destroys peer-to-peer protocols." You have
> to draw an arbitrary distinction between machines that work together,
> "servers," and ones that don't, "clients."

Indeed.

> 
> The problem will become more and more apparent as ipv4 space dries up
> and everyone becomes a client. Although ISPs will be more than happy to
> sell you a useful connection, for a premium.

This has happened to a friend of mine...and he *can't* get a public IP
from his rural ISP.

> 
> Un-NATed addresses are like, type-O blood. Imagine how much better off
> we'd be if we could get everyone to switch their blood to type-O. Might
> be less painful than the ipv6 transition, too =)
> 
> 
>>> or who's tried hosting a Teamspeak or Ventrillo server, has had NAT
>>> get in their way as well.
>>
>>   Port-forwarding.
>>
> 
> Port forwarding can work, but only for one host when the ports are
> standardized. You can't forward e.g. port 443 to two hosts, so only one
> host behind the NAT can be accessible on 443.
> 
> If you're using your NAT as a firewall for one box, then who cares. But
> you can't put more than one machine behind it and have everything still
> work.

Since we've already run out of IPv4 addresses, port forwarding is
starting to fail even for that circumstance; if your ISP hands you an
RFC1918 address, you're screwed.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Alan McKinnon]

On 10/03/2013 03:42, Walter Dnes wrote:
> On Fri, Mar 08, 2013 at 07:41:13PM -0500, Michael Mol wrote
> 
>> The trouble with NAT is that it destroys peer-to-peer protocols. The
>> first was FTP in Active mode.
> 
>   In its day, it was OK.  Nowadays, we use passive mode.  What's the
> problem?
> 
>> SIP has been heavily damaged as well.  Anyone who's used IRC is
>> familiar with the problems NAT introduces to DCC.
> 
>   Every ADSL router-modem I've run into recently has port-forwarding.
> 
>> Anyone who's ever played video games online,...
> 
>   A *CLIENT* that can't operate from behind NAT is totally brain-dead.
> 
>> or who's tried hosting a Teamspeak or Ventrillo server, has had NAT
>> get in their way as well.
> 
>   Port-forwarding.


All those examples you give are much like a bunch of home machines
sitting behind a NAT gateway onto the internet. That's actually OK and I
reckon that is the intended use of NAT. Personally, I'd prefer all of my
machines to have a public address but there's no chance in hell my
NetOps colleagues are giving me that with my DSL connection.

We have any years of experience now with consumer connections and the
users that use them, these guys mostly can't admin a machine to save
their lives, so NAT in their case is a good thing on balance.

The true evil of NAT comes about when some clown starts implementing it
on the network itself. I'm in city X, we have a large office in city Y,
and most of the traffic Y->X goes through a *router* doing NAT. No-one
knows anymore why this was originally done but we all know what it will
take to undo it. To get our backend systems to work for client in city Y
I have to put in the cursed "any any" firewall rules, and that sends our
Risk fellows ballistic for good reason. But I have no choice, the
network design essentially discarded all information as to who the
client is, so now I must allow all of them.

Any real-life network that grew organically over several years is always
going to be rife with examples of fuck ups like this, always done in the
name of expediency. I have lots of such examples, the above is only the
first that came to mind.

So whereas NAT behind a home router for IPv4 is good, in almost every
other usage I've seen it is bad and really just a case of a solution
used in places it never ever belonged.





-- 
Alan McKinnon
alan.mckinnon@gmail.com

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

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 3760 bytes --]

On 03/10/2013 12:19 AM, Alan McKinnon wrote:
> On 10/03/2013 03:42, Walter Dnes wrote:
>> On Fri, Mar 08, 2013 at 07:41:13PM -0500, Michael Mol wrote
>> 
>>> The trouble with NAT is that it destroys peer-to-peer protocols.
>>> The first was FTP in Active mode.
>> 
>> In its day, it was OK.  Nowadays, we use passive mode.  What's the 
>> problem?
>> 
>>> SIP has been heavily damaged as well.  Anyone who's used IRC is 
>>> familiar with the problems NAT introduces to DCC.
>> 
>> Every ADSL router-modem I've run into recently has
>> port-forwarding.
>> 
>>> Anyone who's ever played video games online,...
>> 
>> A *CLIENT* that can't operate from behind NAT is totally
>> brain-dead.
>> 
>>> or who's tried hosting a Teamspeak or Ventrillo server, has had
>>> NAT get in their way as well.
>> 
>> Port-forwarding.
> 
> 
> All those examples you give are much like a bunch of home machines 
> sitting behind a NAT gateway onto the internet. That's actually OK
> and I reckon that is the intended use of NAT.

I want to point out that that's only true if the home network has at
least one public IP. If you've got NAT 4x4, you're kinda screwed.

(Alan will understand that, but for those unfamiliar with it, that
basically means that if your home router is given an RFC1918 address by
your ISP, port forwarding isn't going to do squat for you.)

I've got a friend in a rural area who can't get a publicly-routable
address. To access his home network from work, he rents a VPS and sets
up a static tunnel.

Such are the evils of NAT.

> Personally, I'd prefer all of my machines to have a public address
> but there's no chance in hell my NetOps colleagues are giving me that
> with my DSL connection.

Well, with IPv6, they're supposed to. ^^

> 
> We have any years of experience now with consumer connections and
> the users that use them, these guys mostly can't admin a machine to
> save their lives, so NAT in their case is a good thing on balance.

There's nothing NAT really offers them that having a default simple
firewall on their network gateway wouldn't solve.

If inbound traffic is part of an established or related connection,
accept it. Otherwise, reject it by default. That's all the security
benefit NAT accomplishes, albeit without mangling any packets.

> 
> The true evil of NAT comes about when some clown starts implementing
> it on the network itself. I'm in city X, we have a large office in
> city Y, and most of the traffic Y->X goes through a *router* doing
> NAT. No-one knows anymore why this was originally done but we all
> know what it will take to undo it. To get our backend systems to work
> for client in city Y I have to put in the cursed "any any" firewall
> rules, and that sends our Risk fellows ballistic for good reason. But
> I have no choice, the network design essentially discarded all
> information as to who the client is, so now I must allow all of
> them.
> 
> Any real-life network that grew organically over several years is
> always going to be rife with examples of fuck ups like this, always
> done in the name of expediency. I have lots of such examples, the
> above is only the first that came to mind.
> 
> So whereas NAT behind a home router for IPv4 is good, in almost
> every other usage I've seen it is bad and really just a case of a
> solution used in places it never ever belonged.

NAT behind a home router is bad, too. For IPv4, it's only necessary
because there aren't enough IPv4 addresses to let everyone have a unique
one. (It's unfortunate we never got DHCP-PD for IPv4; that would solve a
number of problems I've seen and foresee with small-business IPv4
networks both pre- and post-crunch.)



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Alan McKinnon]

On 10/03/2013 23:07, Michael Mol wrote:
>> All those examples you give are much like a bunch of home machines 
>> > sitting behind a NAT gateway onto the internet. That's actually OK
>> > and I reckon that is the intended use of NAT.
> I want to point out that that's only true if the home network has at
> least one public IP. If you've got NAT 4x4, you're kinda screwed.
> 
> (Alan will understand that, but for those unfamiliar with it, that
> basically means that if your home router is given an RFC1918 address by
> your ISP, port forwarding isn't going to do squat for you.)


I'm getting images of NATted traffic being NATted. My head just exploded.



-- 
Alan McKinnon
alan.mckinnon@gmail.com

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

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

On 03/10/2013 05:43 PM, Alan McKinnon wrote:
> On 10/03/2013 23:07, Michael Mol wrote:
>>> All those examples you give are much like a bunch of home machines 
>>>> sitting behind a NAT gateway onto the internet. That's actually OK
>>>> and I reckon that is the intended use of NAT.
>> I want to point out that that's only true if the home network has at
>> least one public IP. If you've got NAT 4x4, you're kinda screwed.
>>
>> (Alan will understand that, but for those unfamiliar with it, that
>> basically means that if your home router is given an RFC1918 address by
>> your ISP, port forwarding isn't going to do squat for you.)
> 
> 
> I'm getting images of NATted traffic being NATted. My head just exploded.

Yup. That's the state of small residential ISPs right now, and why it's
so critical to get IPv6 deployed.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Walter Dnes]

On Sun, Mar 10, 2013 at 05:07:25PM -0400, Michael Mol wrote

> NAT behind a home router is bad, too. For IPv4, it's only necessary
> because there aren't enough IPv4 addresses to let everyone have a unique
> one.

  The best real reason for moving to IPV6 is address space (or lack
thereof, in the case of IPV4).  The people who are truly interested in
speeding up IPV6 adoption should do their best to shut up the internet
hippies who constantly rant and rave about how "NAT is evil".  Don't let
the cause get distracted by that unrelated issue.  Focus on the core
issue.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 3742 bytes --]

On 03/11/2013 12:00 AM, Walter Dnes wrote:
> On Sun, Mar 10, 2013 at 05:07:25PM -0400, Michael Mol wrote
> 
>> NAT behind a home router is bad, too. For IPv4, it's only necessary
>> because there aren't enough IPv4 addresses to let everyone have a unique
>> one.
> 
>   The best real reason for moving to IPV6 is address space (or lack
> thereof, in the case of IPV4).  The people who are truly interested in
> speeding up IPV6 adoption should do their best to shut up the internet
> hippies who constantly rant and rave about how "NAT is evil".  Don't let
> the cause get distracted by that unrelated issue.  Focus on the core
> issue.

They're two sides of the same coin. If NAT wasn't such a problem,
layering RFC1918 address space would solve most of the address space
problems. The address space crunch remains a technical problem largely
because NAT can't solve it to completion.

NAT forces a distinction between 'client' and 'server', breaking the
'peer' nature of the network. This isn't some hippy egalitarian thing,
it means I can't trivially tell my VPS to connect to a backup target on
a different network without setting up either a tunnel or a port
forward. With IPv6, doing this is so brain-dead easy I never want to be
without it again. Once you've experienced IPv6 and appropriate network
firewalls, along with the ease of connecting to your own machines from
anywhere you want without having to bounce through a third-party
management service like Teamviewer, you never want to go back. It's like
discovering you've been holding a pencil wrong all your life, or like
discovering a better way to tie your shoes; the solution is simple,
elegant and surprisingly productive. NAT is like tying your shoes wrong;
you don't know how much of a problem it is until you experience life
without it.

And even once you get people comfortable with deploying IPv6, they still
want to hold on to NAT; it's like a stubborn stain on their minds.

It's important to explain that NAT isn't a security measure. In order to
operate, it requires what amounts to a stateful firewall...but that
doesn't mean that a stateful firewall is difficult to obtain without
NAT. People have grown so accustomed to the presence of NAT and NAT's
inherent implications on inbound traffic that they wind up conflating
the two in their minds, making actual understanding of their network's
security that much more difficult to comprehend. So, yeah, NAT is evil.

Looking for privacy in your addresses? That's what privacy extensions
are for, and they're enabled by default on Windows and Ubuntu. (I
haven't looked on Gentoo...)

The only reasonably valid use case for NAT that I've seen is for dealing
with the question of multi-homing an office with two internet
connections. The idea is that you don't have to renumber your internal
network if you need to switch from your primary connection to your
backup connection (and you're being granted different IP ranges based on
which connection you're working with...so we're talking small business,
not BGP or multilink with the same ISP).

In those cases, I advocate application-layer gateways; chances are, if
you're investing in multi-homing your office, you probably already want
the kind of administrative power (and performance improvements) proxy
servers can offer you.

The IPv4 address crunch triggered the development of DNAT a couple
decades ago, and the silly thing persists in terrible ways when there
are simpler ways to handle things. (When I say 'simpler', I mean: Don't
break assumptions about basic network behavior such as 'don't mangle my
packets' or 'I can open a connection back to him when I have updates he
needs')




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Alan McKinnon]

On 11/03/2013 06:00, Walter Dnes wrote:
> On Sun, Mar 10, 2013 at 05:07:25PM -0400, Michael Mol wrote
> 
>> NAT behind a home router is bad, too. For IPv4, it's only necessary
>> because there aren't enough IPv4 addresses to let everyone have a unique
>> one.
> 
>   The best real reason for moving to IPV6 is address space (or lack
> thereof, in the case of IPV4).  The people who are truly interested in
> speeding up IPV6 adoption should do their best to shut up the internet
> hippies who constantly rant and rave about how "NAT is evil".  Don't let
> the cause get distracted by that unrelated issue.  Focus on the core
> issue.
> 

You are being over-simplistic.

Lack of IPv4 address space *caused* NAT to happen, the two are
inextricably intertwined. Even worse, people now have NAT conflated with
all sorts of other things. Like for example NAT and security.

NAT is the context of an IPv6 discussion is *very* relevant, it's one of
the points you have to raise to illustrate what bits inside people's
heads needs to be identified and changed.

Until you change the content of people's heads, IPv6 is just not going
to happen.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

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

[Walter Dnes]

On Mon, Mar 11, 2013 at 10:22:39AM +0200, Alan McKinnon wrote

> You are being over-simplistic.
> 
> Lack of IPv4 address space *caused* NAT to happen, the two are
> inextricably intertwined.

  Agreed.  But we shouldn't be pointing out that NAT has partially solved
the problem, and giving people false hope that NAT will solve the
shortage problem forever.   We should be pounding away on the fact that
we're running out of IP addresses... period... end of story.  If people
ask about NAT, then mention that the undersupply will be so bad that
even NAT won't help.

> Even worse, people now have NAT conflated with all sorts of other
> things. Like for example NAT and security.

  That's why I wwant to avoid that propaganda battle.  It's been lost
already.  Deal with it.  Don't waste time and effort on it.  Put your
effort into pounding away on a simple issue that people do understand...
we're running out of IP addresses.

> NAT is the context of an IPv6 discussion is *very* relevant, it's
> one of the points you have to raise to illustrate what bits inside
> people's heads needs to be identified and changed.
> 
> Until you change the content of people's heads, IPv6 is just not
> going to happen.

  I disagree with you there.  IPV6 adoption will be driven by shortage
of addresses, which people can understand.  It will not be accomplished
by sermons about the evils of NAT whilst people's eyes glaze over.
"A preachment, dear friends, you are about to receive, is on John
Barleycorn, Nicotine, and the Temptations of NAT".

  And if it comes down to it, I'd much rather have IPV6 with IPV6 NAT
being available, rather than no IPV6.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[Kevin Chadwick]

> Don't waste time and effort on it.  Put your
> effort into pounding away on a simple issue that people do understand...
> we're running out of IP addresses.

We have run out of unallocated ones, there are still loads of unused
ones and even more due to global NAT, and even some being released.

It is true eventually it will be an absolute problem but hopefully by
then we will have a cleaner ipv7. Lets hope ISPs get smarter as
recently they have gone downhill with all their *DANGEROUS* as cited by
snort.org and compulsory layer 7 sifting.

Until ipv6 is revised I can't see a day when there will be no ipv4.

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

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

[Walter Dnes]

On Mon, Mar 11, 2013 at 11:39:35PM +0000, Kevin Chadwick wrote
> > Don't waste time and effort on it.  Put your
> > effort into pounding away on a simple issue that people do understand...
> > we're running out of IP addresses.
> 
> We have run out of unallocated ones, there are still loads of unused
> ones... and even some being released.

  And they'll run out rather quickly at the rate they're being assigned.
There are approximately 3.7 billion usable IPV4 addresses.  Soon, that
will be one for every 2 people on this planet.  And don't forget the
people who have an account at home, a smartphone with web access, and an
internet-connected desktop at work.  Conservation of IP addresses will
buy us a couple more years, but that's it.

> and even more due to global NAT...

  In another message you said...

> ...and may I state again also that I have externally facing servers
> and games machines behind NAT.

  Yes, that works if *YOU* have at least 1 public IP address and *YOU*
control port-forwarding.  But it won't work behind carrier-level NAT.

> It is true eventually it will be an absolute problem but hopefully by
> then we will have a cleaner ipv7.

  It won't happen.  It's too late to start from scratch, and the IPV6
rollout has already begun.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[Alan McKinnon]

On 12/03/2013 00:45, Walter Dnes wrote:
>> NAT is the context of an IPv6 discussion is *very* relevant, it's
>> > one of the points you have to raise to illustrate what bits inside
>> > people's heads needs to be identified and changed.
>> > 
>> > Until you change the content of people's heads, IPv6 is just not
>> > going to happen.
>   I disagree with you there.  IPV6 adoption will be driven by shortage
> of addresses, which people can understand.  It will not be accomplished
> by sermons about the evils of NAT whilst people's eyes glaze over.
> "A preachment, dear friends, you are about to receive, is on John
> Barleycorn, Nicotine, and the Temptations of NAT".
> 
>   And if it comes down to it, I'd much rather have IPV6 with IPV6 NAT
> being available, rather than no IPV6.

Hmmm, I'm still not convinced.

NAT (plus a whole boat load of other crap we've accumulated over the
years, NAT merely being the well-known poster-boy) is so ingrained in
people's heads it is now one of those things that we have to deal with.
Ignoring it (and the other crap too) is not going to change that it
really is up at the top of people's thought process.

When I say "people" I of course mean "people I interact with". I don't
claim to speak for all persons who deal with the internet somehow.

Yes, we should and must pound away that IPv4 is a limited resource and
it's close to being used up. But we still have to deal with the other
objections that rightly or wrongly get dumped on the table too.

Why do I think we must deal with these other issues rather than
concentrate on the major one? Because the other guy won't let it go and
won't really engage a discussion about IPv6 for real as he's sitting
with all these other objections uppermost in his mind. Chief amongst
them is the knowledge that he will have to redesign his entire network
from scratch (we all know that IPv6 is not a drop-in replacement for
IPv4) and the fear that somehow he has to keep business going and the
lights on while doing it. That scares people. Well, that's my experience
anyway.

Some days it feels like getting Kuthrapauli to talk to women. We know
all he needs to do is talk to them. He can't get past the thought that
he has to find a glass of wine first...



-- 
Alan McKinnon
Systems Engineer^W Technician
Infrastructure Services
Internet Solutions

+27 11 575 7585


-- 
Alan McKinnon
alan.mckinnon@gmail.com

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

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 5127 bytes --]

On 03/11/2013 06:45 PM, Walter Dnes wrote:
> On Mon, Mar 11, 2013 at 10:22:39AM +0200, Alan McKinnon wrote
> 
>> You are being over-simplistic.
>> 
>> Lack of IPv4 address space *caused* NAT to happen, the two are 
>> inextricably intertwined.
> 
> Agreed.  But we shouldn't be pointing out that NAT has partially 
> solved the problem, and giving people false hope that NAT will solve 
> the shortage problem forever.

The truth of the matter is that it kinda does, for most of these people.
For most of those for whom it doesn't, there are (and will be) plenty of
third-party services looking to allow them to throw money at the problem
for an opaque solution. (It's like sausage; it works, it's nutritious,
it tastes great...but YMMV if you see how it's made.)

For small businesses for whom the IP shortage already crowded out of
traditional network management, the Cloud was born. Large businesses
make a mess of their networks, but hobble along.

So workarounds were developed. What NAT has *done*, though, is force a
stratification and classification of services, making vast swaths of
network applications impossible or incredibly niche.

If one doesn't acknowledge the truth of the matter, one gets nailed to
the wall with it when someone smart enough to consider it brings it up
as a counterpoint.

> We should be pounding away on the fact that we're running out of IP 
> addresses... period... end of story.  If people ask about NAT, then 
> mention that the undersupply will be so bad that even NAT won't 
> help.

In my presentations, I've stopped bothering to wait for people to ask
about NAT, because it starts off in their minds from nearly the
beginning--and until they get that question answered, most of what I say
washes past them as ancillary and not as important as the question
pressing on their minds.

> 
>> Even worse, people now have NAT conflated with all sorts of other 
>> things. Like for example NAT and security.
> 
> That's why I wwant to avoid that propaganda battle.  It's been lost 
> already.  Deal with it.  Don't waste time and effort on it.  Put your
> effort into pounding away on a simple issue that people do 
> understand... we're running out of IP addresses.

That's the thing. We're running out, we've *run* out. Past tense. I keep
pointing to my friend whose ISP hands him RFC1918 addresses as an
example, because that's just the way things are. I can also point to
mobile carriers--most local network regions hand out RFC1918 addresses
for IPv4, which means you're double-NATting if you use your phone to
share your network connection.

At one point a couple *years* ago, my T-Mobile phone told me it had what
I thought was a public IPv4 address...but it turned out to be an address
owned by some security-related branch of the British government who
didn't advertise routes, and so T-Mobile was able to use British
government netblocks internally as a kind of extension to RFC1918 space.

Around the same time, a friend's Verizon phone in the area had a legit
public IPv4 address if and only if he was sharing his network connection
at that moment...otherwise Verizon would switch him back to an RFC1918
address.

So, I say again, we've run out of IPv4 addresses. Past tense. What's
left after that is to explain why most of the people you'll ever talk to
don't feel pain from it, and explain to them why their anaesthetic is
keeping them from realizing their network is paraplegic.

> 
>> NAT is the context of an IPv6 discussion is *very* relevant, it's 
>> one of the points you have to raise to illustrate what bits inside
>>  people's heads needs to be identified and changed.
>> 
>> Until you change the content of people's heads, IPv6 is just not 
>> going to happen.
> 
> I disagree with you there.  IPV6 adoption will be driven by shortage
>  of addresses, which people can understand.

I agree. The problem is that the IPv4 network as it exists today is
highly optimized for asymmetric client-server topologies, and the pains
and breakages will largely go unnoticed or unattributed due to the
layers upon layers of abstractions, band-aids and jerry-rigging.

As a consequence, it's necessary to help people understand what they're
missing.

> It will not be accomplished by sermons about the evils of NAT whilst
> people's eyes glaze over. "A preachment, dear friends, you are about
> to receive, is on John Barleycorn, Nicotine, and the Temptations of
> NAT".

I don't tend to encounter peoples' eyes glazing over. All my
presentations are in Q&A format. There's one guy who's gone to four of
them, because, as he told me, "it's different every time."

> 
> And if it comes down to it, I'd much rather have IPV6 with IPV6 NAT 
> being available, rather than no IPV6.

Sure. I think IPv6 NAT has its place, but I personally feel it should be
done above layer 3, in application-layer gateways. If you're in a
scenario where you need IPv6 NAT, you're almost certainly in a scenario
where you would benefit from the additional features an ALG would give you.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Alan McKinnon]

On 12/03/2013 04:02, Michael Mol wrote:
>> We should be pounding away on the fact that we're running out of IP 
>> > addresses... period... end of story.  If people ask about NAT, then 
>> > mention that the undersupply will be so bad that even NAT won't 
>> > help.
> In my presentations, I've stopped bothering to wait for people to ask
> about NAT, because it starts off in their minds from nearly the
> beginning--and until they get that question answered, most of what I say
> washes past them as ancillary and not as important as the question
> pressing on their minds.
> 

In one short paragraph you said exactly what I was trying to say in 4
mails (and still didn't succeed)



-- 
Alan McKinnon
alan.mckinnon@gmail.com

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

[Kevin Chadwick]

On Tue, 12 Mar 2013 13:29:38 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> >> We should be pounding away on the fact that we're running out of
> >> IP   
> >> > addresses... period... end of story.  If people ask about NAT,
> >> > then mention that the undersupply will be so bad that even NAT
> >> > won't help.  
> > In my presentations, I've stopped bothering to wait for people to
> > ask about NAT, because it starts off in their minds from nearly the
> > beginning--and until they get that question answered, most of what
> > I say washes past them as ancillary and not as important as the
> > question pressing on their minds.
> >   
> 
> In one short paragraph you said exactly what I was trying to say in 4
> mails (and still didn't succeed)

You know I agree except the only people that brought NAT up and
got fixated on it were those that were advocating ipv6!?!?

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

[Kevin Chadwick]

> >> NAT behind a home router is bad, too. For IPv4, it's only necessary
> >> because there aren't enough IPv4 addresses to let everyone have a unique
> >> one.  
> > 
> >   The best real reason for moving to IPV6 is address space (or lack
> > thereof, in the case of IPV4).  The people who are truly interested in
> > speeding up IPV6 adoption should do their best to shut up the internet
> > hippies who constantly rant and rave about how "NAT is evil".  Don't let
> > the cause get distracted by that unrelated issue.  Focus on the core
> > issue.
> >

I completely agree divide and conquer tactics.

> 
> You are being over-simplistic.
> 
> Lack of IPv4 address space *caused* NAT to happen, the two are
> inextricably intertwined. Even worse, people now have NAT conflated with
> all sorts of other things. Like for example NAT and security.
> 

NAT was around way earlier and may I state again also that I have
externally facing servers and games machines behind NAT.

So are you saying that you think it is good for every machine to be in
a DMZ, few chosen ones yes. I disagree completely as I do with the
usefullness of push-email.

> NAT is the context of an IPv6 discussion is *very* relevant, it's one of
> the points you have to raise to illustrate what bits inside people's
> heads needs to be identified and changed.
> 
> Until you change the content of people's heads, IPv6 is just not going
> to happen.

NAT has more uses than those two, NAT type of functionality is
apparently desired by some ipv6 networks to allow easier ISP
migration.

It's true NAT distracts from the bad points of ipv6 and which is the
only part irrelevent for ipv4 modded to work with a larger address space
(ipv5).

I wonder if this is an example of how these technologies can get so
convoluted?

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

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

[Alan McKinnon]

On 12/03/2013 01:31, Kevin Chadwick wrote:
>>>> NAT behind a home router is bad, too. For IPv4, it's only necessary
>>>> because there aren't enough IPv4 addresses to let everyone have a unique
>>>> one.  
>>>
>>>   The best real reason for moving to IPV6 is address space (or lack
>>> thereof, in the case of IPV4).  The people who are truly interested in
>>> speeding up IPV6 adoption should do their best to shut up the internet
>>> hippies who constantly rant and rave about how "NAT is evil".  Don't let
>>> the cause get distracted by that unrelated issue.  Focus on the core
>>> issue.
>>>
> 
> I completely agree divide and conquer tactics.
> 
>>
>> You are being over-simplistic.
>>
>> Lack of IPv4 address space *caused* NAT to happen, the two are
>> inextricably intertwined. Even worse, people now have NAT conflated with
>> all sorts of other things. Like for example NAT and security.
>>
> 
> NAT was around way earlier and may I state again also that I have
> externally facing servers and games machines behind NAT.

I fail to see your point, and you have answered a question I did not ask.

I too have that same circumstance, as likely does every one else here
who works in networks for a living. So what? We have that because the
environment gives us little choice. It doesn't make it good, bad,
desirable or undesirable. it simply is and we have few realistic
alternative choices.

> 
> So are you saying that you think it is good for every machine to be in
> a DMZ, few chosen ones yes. 

That's also a question I did not ask, and one I do not care to debate.

>I disagree completely as I do with the
> usefullness of push-email.
> 
>> NAT is the context of an IPv6 discussion is *very* relevant, it's one of
>> the points you have to raise to illustrate what bits inside people's
>> heads needs to be identified and changed.
>>
>> Until you change the content of people's heads, IPv6 is just not going
>> to happen.
> 
> NAT has more uses than those two, NAT type of functionality is
> apparently desired by some ipv6 networks to allow easier ISP
> migration.

You are going to have to back that up with some reasoned arguments.

The only reason I can see why some might desire that is their reluctance
to give up on old habits. happy to be shown to be wrong though.


> 
> It's true NAT distracts from the bad points of ipv6 and which is the
> only part irrelevent for ipv4 modded to work with a larger address space
> (ipv5).
> 
> I wonder if this is an example of how these technologies can get so
> convoluted?

McKinnon's Law of Human Implementation of Solutions:

Any sufficiently large and representative group of humans when faced
with making new choices to solve old problems, will always decide on the
most complex convoluted solution that can be implemented soonest.

Relevant? I dunno. But it sure sounds good.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

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

[Kevin Chadwick]

> > What would have been best, could have been done years ago and not cost
> > lots of money and even more in security breaches and what I meant by
> > ipv5 and would still be better to switch to even today with everyone
> > being happy to switch to it is simply ipv4 with more bits for address
> > space.  
> 
>   This should be FAQ entry zero for the IPV6 FAQ... *NO* you can *NOT*
> add more bits to IPV4, and still have it backwards compatable.  It won't
> work... period... end of story.  Every piece of hardware and software
> that deals with IPV4 has the concept of 32 bits *HARD-CODED* into it.
> Switching over to IPV4-extended would be just as painfull as switching
> over to IPV6.

No it would not, the headers would be different. All the hardware would
have already updated because there would be no bad sides and it would
have been released something like 15 years ago. But lets not discuss
them as we would be here for an eternity and there are already whole
websites dedicated to just that.

I re-iterate it would be worth hardware not being backwards compatible
again to go to ipv4 with large address space today.

http://www.hackingipv6networks.com/past-trainings/hip2011-hacking-ipv6-networks.pdf

That's just on security. There's a whole bad side to it's functionality
too.

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

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

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 14781 bytes --]

On 03/08/2013 07:45 PM, Kevin Chadwick wrote:
>>> What would have been best, could have been done years ago and
>>> not cost lots of money and even more in security breaches and
>>> what I meant by ipv5 and would still be better to switch to even
>>> today with everyone being happy to switch to it is simply ipv4
>>> with more bits for address space.
>> 
>> This should be FAQ entry zero for the IPV6 FAQ... *NO* you can 
>> *NOT* add more bits to IPV4, and still have it backwards 
>> compatable.  It won't work... period... end of story.  Every piece 
>> of hardware and software that deals with IPV4 has the concept of 32
>> bits *HARD-CODED* into it. Switching over to IPV4-extended would be
>> just as painfull as switching over to IPV6.
> 
> No it would not, the headers would be different. All the hardware 
> would have already updated because there would be no bad sides and
> it would have been released something like 15 years ago. But lets
> not discuss them as we would be here for an eternity and there are 
> already whole websites dedicated to just that.

I don't know, you just dropped the 2-3 most trollish anti-IPv6 posts
I've ever seen.


> 
> I re-iterate it would be worth hardware not being backwards 
> compatible again to go to ipv4 with large address space today.

"IPv4 with large address space" would have taken just as long to deploy;
it's the hardware support that's held us back the most.

> 
> http://www.hackingipv6networks.com/past-trainings/hip2011-hacking-ipv6-networks.pdf
>
> That's just on security. There's a whole bad side to it's
> functionality too.
> 

Let's discuss security. I'll walk through the slide deck.

"We have much less experience with IPv6 than with IPv4"

That's a meaningless statement...

"IPv6 implementations are much less mature than their IPv4 counterparts."

Only in hardware Software has been much better. Windows has had full
IPv6 support since Vista. Linux has
had full IPv6 support for a few years, including IPSec. The software
implementations are written...the stuff that's still arriving is
feature-add.

Offload engines and managed switches haven't switched over because
clients were more interested in putting off a transition (the same
transition you'd have to go through for IPv4 with extended address
space) than paying for the upgrades. This would have happened with any
IPv4 replacement.

"Security products (firewalls, NIDS, etc.) have less support for IPv6
than for
IPv4"

Dedicated commercial products, yes. General-purpose products? Like I
said, Windows Vista made IPv6 a first-class protocol, including firewall
support. Linux's implementation is a bit quirky. I don't care for the
separation between iptables and ip6tables; I think people tend to write
an iptables script and forget to set up a firewall of any kind for IPv6.
Most of the builder tools (i.e. fwbuilder), require seperate setup
between the two, too.

That's why I use sanewall (formerly firehol); defined rules apply to
both IPv4 and IPv6.

"The complexity of the resulting network will greatly increase during
the transition/co-existence period:"

Yes, and that would apply to any transition period.

"Lack of trained human resources"

That's why people like me go out and do training sessions. (I'll be at
Penguicon again this year, if anyone else was thinking about going...)
That's why Hurricane Electric offers free online certification programs.

Regarding flow labels:

"Currently unused by many stacks – others use it improperly"

Honestly, I don't know about this. It's not something most people will
need to work with.

"Might be leveraged to perform “dumb” (stealth) address scans"

I don't understand the relevance; you get the same information by
observing the packet flow without the flow label.

"Might be leveraged to perform Denial of Service attacks"

So might absolutely anything.

Regarding hop limit:

"Could be leveraged for Detecting the Operating System of a remote node"

So can IPv4's TTL, which it's analogous to.

"Could be leveraged for Fingerprinting a remote physical device"

So can IPv4's TTL, which it's analogous to.

"Could be leveraged for Locating a node in the network topology"

tcptraceroute does this with IPv4 TTLs. And traceroute has been doing
this with IPV4's ICMP echo for decades.

"Could be leveraged for Evading Network Intrusion Detection Systems (NIDS)"

Just like IPv4 TTL.

"Could be leveraged for Reducing the attack exposure of some
hosts/applications"

Not sure what's being said here, but we're talking about a feature
directly analogous to IPv4 TTL.

(skipping the remainder of the section, as there's nothing in there
that's bad that's unique to IPv6)

(skipping the next several sections, as they're just general technical
training material, and don't discuss security implications)

Re Fragmentation security implications that are different from IPv4:

"The Identification field is much larger: chances of “IP ID collisions”
are reduced"

Good thing.

"Note: Overlapping fragments have been recently forbidden (RFC 5722) –
but they are still allowed by many Oses"

This will improve.

"IPv6 Idle scan"

Noted as being applicable to IPv4.

(skipping some general technical material aimed at sysadmin use for
securing their systems)

(skipping description of IPv6 headers; basic technical information)

(skipping suggested countermeasures for theorized attacks)

"IPv6 can be easily leveraged for evading firewalls."

Not if the firewall is set up properly to begin with. Part of that is
described in the preceding 'countermeasures' section. Most of the
remainder is leveraging the same source, dest, port and state data
that's known in IPv4. Finally, use IPSec if possible. (Right now, IPSec
is largely useful as a VPN technique natively supported by by layer 3)

"Most likely, firewalls will block packets with extension headersEs muy
probable que se haga común el filtrado (en firewalls) de paquetes que
contengan en encabezados de extensión"

Not really; firewalls will continue to be based on known factors, and
most of the interesting known factors are in the first header, not the
extension headers.

"The result will be: less flexibility, possibly preventing any use of
IPv6 exntesion headers"

Extension headers will be used where appropriate.

(skip more benign material)

"Some ICMPv6 messages are assumed to indicate “hard errors”. Some stacks
used to abort TCP connections when hard errors were
received. BSD-derived and Linux implementations don’t--Good!"

I believe Windows's stack is based on BSD. I don't know of any stacks
which do. (None are listed, either)

(skip portion which notes straightforward solutions)

(skip benign material)

Re ICMPv6 Echo Request/Echo response

"Also usually exploited for network reconnaissance"

A.K.A. 'traceroute', a known entity in IPv4.

(skip benign material)

Re Node Information Query/Response

"My take: unless you really need your nodes to support Node Information
messages, disable it (i.e., “sysctl –w net.inet6.icmp6.nodeinfo=0)."

Or even firewall it off at your network edge, like you would any
unblessed, unsolicited inbound traffic.

(skip benign material)

Re Address Resolution Games

"Neighbor Cache Poisoning attacks – the v6 version of V4’s ARP cache
poisoning"

Says it for me...same as IPv4's ARP poisoning. (Incidentally, this is
the attack bandied about the most by people arguing that IPv6 is insecure)

"Advertising “special” link-layer addresses, e.g.,"

That's probably a bug in the implementation. It will be fixed.

"Some implementations (FreeBSD, NetBSD) don’t enforce limits on the
number of entries that can be created in the Neighbor Cache"

Certainly that will change soon.

(Skipping MitM and DoS discussion, as it's analogous to IPv4's ARP
poisoning)

"Not much support in layer-2 security boxes to mitigate these attacks"

This is improving. It hadn't shown up yet because commercial purchasers
had been dragging their feet in demanding their vendors support IPv6 in
the first place.

(skip more benign material)

"Disable an Existing Router"

Depends on the attacker being on the local network, and is what RAGuard
is for.

"Exploit DAD for Denial of Service"

This is the first interesting attack I've seen mentioned in the slide
deck (and I'm on slide 109 out of 167, getting to it).

I don't think there's a way to mitigate against it, except to prevent
the attacker from getting on layer 2 network in the first place.
(Entirely doable with things like 802.1x.)

"Advertise Malicious Network Parameters"

Again, what RAGuard is for.

Re Autoconf Addresses & Privacy

"There were concerns that autoconf addresses hurt privacy, as they could
be used to correlate network activity"

Not all that interesting, actually. That kind of correlating activity is
happening more effectively with DPI and HTTP request headers, and *that*
sees through NAT, privacy addresses and proxy servers.

When people express concerns about autoconf addresses to me, I tell them
that if they're that worried about it, they need to already be using
source-obfuscating techniques like the Tor network.

(skip benign material)

"The use of a single “Destination Options” header is enough to evade
most implementations of RA-Guard."

Sadly, that's on the hardware vendors again. Hopefully, the
commercial-grade vendors will get their crap patched. There's no reason
(that I know of) for an RA-Guard implementation to need to inspect the
destination options header.

"This technique can also be exploited to circumvent Neighbor Discover
monitoring tools such as NDPMon"

I don't know so much about this attack, honestly.

Re DHCPv6

"It can be exploited in a similar way to Router Advertisement messages."

And protected in the same way.

Re MLD

"Potential issues: If a MLD-snooping switch is employed, MLD could be
exploited for Denial of Service attacks."

Largely the same class of attacks as if the attacker is on the local
segment. Enable MLD snooping if and only if you're willing to expand
your attack surface in that way. That's not a difficult question; it's
similar to asking whether you want to use a wireless bridge to a wired
network, or if you want to use a router instead.

Re IPSec

"IPsec support is currentlymantatory for IPv6 implementations – the IETF
is changing this requirement to “optional” thus acknowledging reality."

I have yet to encounter a widely-used IPv6 stack that does not support
IPSec. *BSD, Linux and Windows all support it. The idea of it being
"optional" is irrelevant to the question of whether it's available for
use by servers and desktop machines.

"Also, many IPv4 implementations support IPsec, while many IPv6
implementations do not."

As I said, I have yet to encounter a widely-used IPv6 stack that doesn't
support IPSec. Actually, I haven't encountered *any* IPv6 stack that
doesn't support IPSec. I imagine the ones that don't are in things like
voip phones.

"Most of the key problems (e.g., PKI) for IPsec deployment in IPv4 apply
to IPv6, as well."

This is true, if you want to use PKI for IPSec deployment. If you're
setting up static relationships between campus endpoints, it's not so
big a deal.

"There is no reason to believe that IPv6 will result in an increased use
of IPsec."

Bull. The biggest barrier to IPsec use has been NAT! If an intermediate
router has to rewrite the packet to change the apparent source and/or
destination addresses, then the cryptographic signature will show it,
and the packet will be correctly identified as having been tampered with!

With IPsec, NAT is unnecessary. (You can still use it if you need
it...but please try to avoid it!)

Re "DNS support for IPv6"

"Increased size of DNS responses due to larger addresses might be
exploited for DDos attacks"

That's not even significant. Have you looked at the size of DNS
responses? The increased size of the address pales in comparison to the
amount of other data already stuffed into the packet.

Re "IPv6 Transition Co-Existence Technologies"

"Original transition plan: deploy IPv6 before we ran out of IPv4
addresses, and eventually turn off IPv4 when no longer needed – it
didn’t happen"

That's correct; the IPv6 deployment didn't happen when it should have.
Instead, a ton of coping mechanisms for a shrinking address pool came
around. NAT is the big one. If IPv6 had been deployed early on, people
wouldn't think of "one IP address per customer" as the norm...and they
shouldn't have to.

"An attacker can connect to an IPv4-only network, and forge IPv6 Router
Advertisement messages. (*)"

Again, this depends on them being on the same layer 2 network segment.

The same class of attacks would be possible for any IPv4 successor that
implemented either RAs or DHCP.

(Yes, you will want to deploy the countermeasures described)

(skipping more benign material)

Re ISATAP

"An attacker could forge name resolution responses to--"

Secure your DNS.

"This could be used in conjunction with other attacks (e.g. forging DNS
responses such that--"

Secure your DNS.

Re Problems with 6to4

Actually, I'm going to skip most of this and simply acknowledge it: Yes.
6to4 sucks. It's terrible and horrible. *Everyone* of low-to-moderate
knowledge in IPv6 knows it. Use 6rd instead if you need that kind of
tunnel; at least you'll know who to yell at if it breaks.

Re Security Implications of Teredo:

Yes, Teredo sucks, too. Disable it.

Re 'Translation'

(pardon the US-centric view, here) All major ISPs have deployed (or are
in the process of deploying) native IPv6. Mobile carriers have deployed
IPv6. Tunnels will be largely unnecessary. NAT will remain, but it will
be more prevalent in IPv4 than in IPv6.

Re 'Exploiting Transition Technologies'

"Some systems (notably Windows) have support of trnasition technologies
enabled by default."

Yes. Disable Teredo. I'm not aware any other distro that enables a
tunneling protocol by default.

(skip benign material.)

Re Application-layer protocols

"A number of applications may leak IPv6 addresses: E-mail headers, P2P
applications"

As far as email headers, that's just as in IPv4. You can examine some
folks' IPv4 RFC1918 topology by their email headers today, so don't tell
me IPv6 brings much new to the table.

As for P2P applications, this is actually a good thing; P2P applications
can use what they learn for more efficient peer association.

(skip the rest, as it's benign)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Kevin Chadwick]

> "There is no reason to believe that IPv6 will result in an increased use
> of IPsec."
> 
> Bull. The biggest barrier to IPsec use has been NAT! If an intermediate
> router has to rewrite the packet to change the apparent source and/or
> destination addresses, then the cryptographic signature will show it,
> and the packet will be correctly identified as having been tampered with!
> 

It's hardly difficult to get around that now is it. You are wrong the
biggest barrier is that it is not desirable to do this as there are
many reasons for firewalls to inspect incoming packets. I don't agree
with things like central virus scanning especially by damn ISPs using
crappy Huawei hardware, deep inspection traffic shaping rather than
pure bandwidth usage tracking or active IDS myself but I do agree
with scrubbing packets.

> With IPsec, NAT is unnecessary. (You can still use it if you need
> it...but please try to avoid it!)
> 

Actually it is no problem at all and is far better than some of the
rubbish ipv6 encourages client apps to do. (See the links I sent in the
other mail)

> Re "DNS support for IPv6"
> 
> "Increased size of DNS responses due to larger addresses might be
> exploited for DDos attacks"
> 
> That's not even significant. Have you looked at the size of DNS
> responses? The increased size of the address pales in comparison to the
> amount of other data already stuffed into the packet.

It's been ages since I looked at that link and longer addresses would
certainly be needed anyway but certainly with DNSSEC again concocted by
costly unthoughtful and unengaging groups who chose to ignore DJB
and enable amplification attacks.

His latest on the "DNS security mess"

http://cr.yp.to/talks/2013.02.07/slides.pdf

> "An attacker can connect to an IPv4-only network, and forge IPv6 Router
> Advertisement messages. (*)"

> Again, this depends on them being on the same layer 2 network segment.

> The same class of attacks would be possible for any IPv4 successor that
> implemented either RAs or DHCP.

Neither of which I use.

As I said we would be here all day and that link wasn't as good as the
one I was actually looking for.

local NAT done right is no problem and actually a good thing and I have
no issues playing games, running servers or anything else behind NAT.
Global NAT works well enough but isn't a good thing and wouldn't exist
if they had simply added more addresses quickly. The hardware uptake
would have been no issue rather than a decade of pleads.

We haven't even touched on the code yet and so all the vulnerable
especially home hardware which yes often has vulnerable sps anyway but
by no way just home hardware.

The ipvshit links give an insight into the code complexity. Note
OpenBSDs kernel which is very secure (unlike Linux whose primary goal is
function) and has had just a few remote holes in well over a decade, one
of which was in ipv6 and which I had avoided without down time because I
won't and what's more shouldn't use ipv6 wherever possible and had
actually removed it from the kernel all together.

If I am Trolling rather than simply trying to make people aware then
stating ipv6 is wonderful is Trolling just as much or more.

Regards,
	Kc

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

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

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 8740 bytes --]

On 03/09/2013 07:53 AM, Kevin Chadwick wrote:
>> "There is no reason to believe that IPv6 will result in an 
>> increased use of IPsec."
>> 
>> Bull. The biggest barrier to IPsec use has been NAT! If an 
>> intermediate router has to rewrite the packet to change the 
>> apparent source and/or destination addresses, then the 
>> cryptographic signature will show it, and the packet will be 
>> correctly identified as having been tampered with!
>> 
> 
> It's hardly difficult to get around that now is it.

Sure, you can use an IP-in-IP tunnel...but that's retarded. IPSec was
designed from the beginning to allow you to do things like sign your IP
header and encrypt everything else (meaning your UDP, TCP, SCTP or what
have you).

Setting up a tunnel just so your IP header can be signed wastes another
40 bytes for every non-fragmented packet. Ask someone trying to use data
in a cellular context how valuable that 40 bytes can be.

> You are wrong the biggest barrier is that it is not desirable to do 
> this as there are many reasons for firewalls to inspect incoming 
> packets. I don't agree with things like central virus scanning 
> especially by damn ISPs using crappy Huawei hardware, deep inspection
> traffic shaping rather than pure bandwidth usage tracking or active
> IDS myself but I do agree with scrubbing packets.

It's not the transit network's job to scrub packets. Do your scrubbing
at the VPN endpoint, where the IPSec packets are unwrapped.

Trusting the transit network to scrub packets is antithetical to the
idea of using security measures to avoid MITM and traffic sniffing
attacks in the first place!

> 
>> With IPsec, NAT is unnecessary. (You can still use it if you need 
>> it...but please try to avoid it!)
>> 
> 
> Actually it is no problem at all and is far better than some of the 
> rubbish ipv6 encourages client apps to do. (See the links I sent in 
> the other mail)

Please read the links before you send them, and make specific references
to the content you want people to look at. I've read and responded to
the links you've offered (which were links to archived messages on
mailing lists, and the messages were opinion pieces with little (if any)
technical material.)

> 
>> Re "DNS support for IPv6"
>> 
>> "Increased size of DNS responses due to larger addresses might be 
>> exploited for DDos attacks"
>> 
>> That's not even significant. Have you looked at the size of DNS 
>> responses? The increased size of the address pales in comparison to
>> the amount of other data already stuffed into the packet.
> 
> It's been ages since I looked at that link and longer addresses
> would certainly be needed anyway but certainly with DNSSEC again
> concocted by costly unthoughtful and unengaging groups who chose to
> ignore DJB and enable amplification attacks.

What from DJB did they ignore? I honestly don't know what you're talking
about.

> 
> His latest on the "DNS security mess"
> 
> http://cr.yp.to/talks/2013.02.07/slides.pdf

I've never before in my life seen someone animate slideshow transitions
and save off intermediate frames as individual PDF pages. That was painful.

So, I read what was discussed there. First, he describes failings of
HTTPSEC. I don't have any problem with what he's talking about there,
honestly; it makes a reasonable amount of sense, considering
intermediate caching servers aren't very common for HTTP traffic, and
HTTPS traffic makes intermediate caching impossible. (unless you've
already got serious security problems by way of a MITM opening.)

Then he turns around and dedicates two slides showing a DNS delegation
sequence...and then states in a single slide that DNSSEC has all the
same problems as HTTPSEC.

DNSSEC doesn't have the same problems as HTTPSEC, because almost *every*
recursive resolving DNS server (which is most of the DNS servers on the
Internet) employs caching.

> 
>> "An attacker can connect to an IPv4-only network, and forge IPv6 
>> Router Advertisement messages. (*)"
> 
>> Again, this depends on them being on the same layer 2 network 
>> segment.
> 
>> The same class of attacks would be possible for any IPv4 successor
>>  that implemented either RAs or DHCP.
> 
> Neither of which I use.

You're telling me you don't use DHCP? Seriously, that you statically
configure the IPv4 addresses of all the hosts on your network?

With one exception, I haven't personally seen a network configured in
that way since 1998! Certainly, every network has some hosts configured
statically, but virtually no network I've observed (and I've seen
private networks between 2 and 50 hosts, and commercial networks between
5 and 30k hosts) managed completely statically.

> 
> As I said we would be here all day and that link wasn't as good as 
> the one I was actually looking for.
> 
> local NAT done right is no problem and actually a good thing and I 
> have no issues playing games, running servers or anything else behind
> NAT.

See others' responses about port standardization, and about how it
enforces a distinction between 'clients' and 'servers' that's
unnecessary (and even harmful) for a variety of applications.

> Global NAT works well enough

With global NAT, anything you do that depends on port forwarding is broken.

> but isn't a good thing and wouldn't exist if they had simply added 
> more addresses quickly. The hardware uptake would have been no issue 
> rather than a decade of pleads.

There's almost nothing you've pointed at so far that would have
prevented backbones from IPv6 uptake...and the backbones dragged their
heels long enough. IPv4 with expanded address bits would have been
worse; IPv6 explicitly includes features intended to ease the strain on
the size of a global routing view!

> 
> We haven't even touched on the code yet and so all the vulnerable 
> especially home hardware which yes often has vulnerable sps anyway 
> but by no way just home hardware.
> 
> The ipvshit links give an insight into the code complexity.

You call that code complex? (and I still don't know what 'ipvshit' is,
except possibly one guy's pejorative description of IPv6)

> Note OpenBSDs kernel which is very secure (unlike Linux whose
> primary goal is function)

I have no complaints about OpenBSD.

> and has had just a few remote holes in well over a decade, one of 
> which was in ipv6

So OpenBSD, who you venerate, had a bug in its IPv6 implementation, and
for that you view IPv6 as an abomination? Is that it? (Or is it because
the guy who wrote the buggy code thinks so, and you venerate him?
Because that seems plausible, too.)

I like Linux, but I don't hold Linux (or any Linux developer) in
veneration. I like Windows, but I don't hold Bill Gates, Balmer or any
Microsoft dev in veneration. I like Android, but I don't hold Google or
any Google employee in veneration. I dislike Macs, but I don't think of
Steve Jobs as evil.

> and which I had avoided without down time because I won't and what's
>  more shouldn't use ipv6 wherever possible

Do you mean that as "I'll avoid IPv6 as much as possible" or do you mean
that as "I won't use IPv6 in all places where it's possible to use IPv6"?

If the latter, I'd agree; there are places you can use IPv6 where it
probably won't make a whole lot of sense (i.e. on an HDMI cable, unless
you have a particular need to provide network traffic to/from your TV).

If the former, I'm afraid I still haven't seen a solid technical case
against it.

> and had actually removed it from the kernel all together.

That's sensible; if you're not going to use code, remove it.

> 
> If I am Trolling rather than simply trying to make people aware then 
> stating ipv6 is wonderful is Trolling just as much or more.

IPv6 fixes things about the Internet that are currently broken by IPv4
address exhaustion. I try to point out where IPv6 fixes things, I try to
clear up popular misconceptions about IPv6, and I try to help people
understand a thing rather than simply fear it.

If you take a highly competent IPv4 network administrator and drop him
into IPv6 territory without ensuring that he has knowledge of IPv6 best
practices and practical concerns, you're likely to get a broken network
out of it. I try to help keep that from happening.

The statements you've made that I regarded as trollish where were you
made emotional statements and arguments without anything explanatory to
back them up. In contrast, I've spent *hours* wading through the links
you've thrown at me (without you yourself reading, I suspect), making
point-by-point responses.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Michael Orlitzky]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/10/2013 06:00 PM, Michael Mol wrote:
>> 
>> It's been ages since I looked at that link and longer addresses 
>> would certainly be needed anyway but certainly with DNSSEC again 
>> concocted by costly unthoughtful and unengaging groups who chose
>> to ignore DJB and enable amplification attacks.
> 
> What from DJB did they ignore? I honestly don't know what you're
> talking about.
> 

This was a non-sequitur as far as I can tell, but I remember the
amplification attack from a talk:

  http://vimeo.com/18279777 (video)
  http://cr.yp.to/talks/2010.12.28/slides.pdf (slides)

It was a really good talk, however you feel about DJB.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJRPTnkAAoJEBxJck0inpOia6EP/1Bu1rhx5cCi6/bl/J3MeJm3
CAaGXQG6iSnxxIXVqVXTs2fioZH2f3Xsq3jvKBoAQfil2ocGQa4LAPSGbLYX99xr
XodEfm530EDK02UsqnyGHX2pzFQzUR/cQ0/SFpd8tMtEiYRdASIT6VtqoJoQWsoA
unvPvK6xxHhH/YwmB+miPUSVl1nvmqT6Z7OKmpQL+MRHCQFvyk7SeClVf8OmAPkn
NX/m3pSbsHdAtj6QP6CU8nAF1QbgWehhvZkx8UxqwPz8n8AO1JfY+zG669B5F6u+
MRcnN1s6jgIVoAgeqvgDjUC8JnkQTGBg3Lkdrv9IcM7N/+4ILvlH6h3IeSiI6unU
hnganpVCl0q03N+qRi3JsHfdR/ZNBEetkplOai/QKyUltKohGG4LLPbqBFEdg+NP
nVWz/Y4wn3h2uasClfIbehxSQDKlbHCvKOLp/dEmcFsra29vAF3pu15V1okmqdwF
qzwf1k7nxoyjCT4YVnQv7F9OwnyYwm3nEmOjQyShJZN3gN82/4b+1R0LyhjeOled
WcF8dnuxNpITjr1OusQ9MUeYmotWX2dj+//6zsrwZVs3QTNyOHx5VVe9Bl3DdcKr
lFthQKyjsQAGgMD7zFoy4JxPReBwTQhu/QGcGKVKLIVRlTJ0XRQWVHUijlVY6dqB
lIZu+xpwtY8OeZ20e+BC
=knjT
-----END PGP SIGNATURE-----

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

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 1498 bytes --]

On 03/10/2013 09:56 PM, Michael Orlitzky wrote:
> On 03/10/2013 06:00 PM, Michael Mol wrote:
>>>
>>> It's been ages since I looked at that link and longer addresses 
>>> would certainly be needed anyway but certainly with DNSSEC again 
>>> concocted by costly unthoughtful and unengaging groups who chose
>>> to ignore DJB and enable amplification attacks.
> 
>> What from DJB did they ignore? I honestly don't know what you're
>> talking about.
> 
> 
> This was a non-sequitur as far as I can tell, but I remember the
> amplification attack from a talk:
> 
>   http://vimeo.com/18279777 (video)
>   http://cr.yp.to/talks/2010.12.28/slides.pdf (slides)
> 
> It was a really good talk, however you feel about DJB.
> 
> 

Didn't watch the video, but I did read the slide deck. It's a good read,
even if I disagree with a number of key points, disagree with the tack
taken as a solution, and further think the presenter cherry-picked his
arguments, amplified inconsequential pieces of the problem space and
skipped over obvious problems with his approach. (Hm. I suspect I'm
formulating an opinion on DJB, and I didn't have one a couple hours
ago...) (That said, he does seem to know how to use slide decks properly!)


I believe Kevin's position is that, while I cited "secure your DNS" in
response to some of the arguments raised by a slide deck he linked to,
"securing your DNS" would likely involve using DNSSEC, which DJB argues
enable amplification attacks.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Kevin Chadwick]

> On 03/09/2013 07:53 AM, Kevin Chadwick wrote:
> >> "There is no reason to believe that IPv6 will result in an 
> >> increased use of IPsec."
> >> 
> >> Bull. The biggest barrier to IPsec use has been NAT! If an 
> >> intermediate router has to rewrite the packet to change the 
> >> apparent source and/or destination addresses, then the 
> >> cryptographic signature will show it, and the packet will be 
> >> correctly identified as having been tampered with!
> >> 

http://marc.info/?l=openbsd-misc&m=135325641430178&w=2

> > 
> > It's hardly difficult to get around that now is it.
> 
> Sure, you can use an IP-in-IP tunnel...but that's retarded. IPSec was
> designed from the beginning to allow you to do things like sign your IP
> header and encrypt everything else (meaning your UDP, TCP, SCTP or what
> have you).
> 
> Setting up a tunnel just so your IP header can be signed wastes another
> 40 bytes for every non-fragmented packet. Ask someone trying to use data
> in a cellular context how valuable that 40 bytes can be.
> 
> > You are wrong the biggest barrier is that it is not desirable to do 
> > this as there are many reasons for firewalls to inspect incoming 
> > packets. I don't agree with things like central virus scanning 
> > especially by damn ISPs using crappy Huawei hardware, deep inspection
> > traffic shaping rather than pure bandwidth usage tracking or active
> > IDS myself but I do agree with scrubbing packets.
> 
> It's not the transit network's job to scrub packets. Do your scrubbing
> at the VPN endpoint, where the IPSec packets are unwrapped.
> 
> Trusting the transit network to scrub packets is antithetical to the
> idea of using security measures to avoid MITM and traffic sniffing
> attacks in the first place!
> 

I never said it was. I was more thinking of IPSEC relaying which would
be analogous to a VPN end point but without losing the end-end, neither
are desirable, NAT has little to do with the lack of IPSEC deployment.

What do you gain considering the increased resources, pointlessly
increasing chances of cryptanalysis and pointlessly increasing the
chances of exploitation due to the fact that the more complex IPSEC
itself can have bugs like Openssl does, not to mention amplifying DDOS
without the attacker doing anything, which is the biggest and more of a
threat than ever, or are you going to stop using the internet. When
ipv4 can utilise encryption without limitations including IPSEC but more
appropriately like ssh just fine when needed you see it is simply not
desirable and a panacea that will not happen. You are simply in a
bubble as the IETF were.

> > 
> >> With IPsec, NAT is unnecessary. (You can still use it if you need 
> >> it...but please try to avoid it!)
> >> 
> > 
> > Actually it is no problem at all and is far better than some of the 
> > rubbish ipv6 encourages client apps to do. (See the links I sent in 
> > the other mail)
> 
> Please read the links before you send them, and make specific references
> to the content you want people to look at. I've read and responded to
> the links you've offered (which were links to archived messages on
> mailing lists, and the messages were opinion pieces with little (if any)
> technical material.)
> 


> > 
> >> Re "DNS support for IPv6"
> >> 
> >> "Increased size of DNS responses due to larger addresses might be 
> >> exploited for DDos attacks"
> >> 
> >> That's not even significant. Have you looked at the size of DNS 
> >> responses? The increased size of the address pales in comparison to
> >> the amount of other data already stuffed into the packet.
> > 
> > It's been ages since I looked at that link and longer addresses
> > would certainly be needed anyway but certainly with DNSSEC again
> > concocted by costly unthoughtful and unengaging groups who chose to
> > ignore DJB and enable amplification attacks.
> 
> What from DJB did they ignore? I honestly don't know what you're talking
> about.
> 

They completely ignored dnscurve.org or that RSA768 was not strong
enough to be a good choice and ECDSA should be looked at and most
importantly the DOS amplification (we are talking years ago). I even had
a discussion with a dns caching tools (that I do like a lot) author who
completely dismissed the potential of RSA being broken for years and
years. Guess what's come to light since.

> > 
> > His latest on the "DNS security mess"
> > 
> > http://cr.yp.to/talks/2013.02.07/slides.pdf
> 
> I've never before in my life seen someone animate slideshow transitions
> and save off intermediate frames as individual PDF pages. That was painful.
> 

Yeah, xpdf worked well though. I actually couldn't find the link
and looked it up and thought it was just an update of 2012 as it had
the same title and only got around to reading it about an hour later.

> So, I read what was discussed there. First, he describes failings of
> HTTPSEC. I don't have any problem with what he's talking about there,
> honestly; it makes a reasonable amount of sense, considering
> intermediate caching servers aren't very common for HTTP traffic, and
> HTTPS traffic makes intermediate caching impossible. (unless you've
> already got serious security problems by way of a MITM opening.)
> 
> Then he turns around and dedicates two slides showing a DNS delegation
> sequence...and then states in a single slide that DNSSEC has all the
> same problems as HTTPSEC.
> 
> DNSSEC doesn't have the same problems as HTTPSEC, because almost *every*
> recursive resolving DNS server (which is most of the DNS servers on the
> Internet) employs caching.
> 

I suggest you read the 2012 slides.

> > 
> >> "An attacker can connect to an IPv4-only network, and forge IPv6 
> >> Router Advertisement messages. (*)"
> > 
> >> Again, this depends on them being on the same layer 2 network 
> >> segment.
> > 
> >> The same class of attacks would be possible for any IPv4 successor
> >>  that implemented either RAs or DHCP.
> > 
> > Neither of which I use.
> 
> You're telling me you don't use DHCP? Seriously, that you statically
> configure the IPv4 addresses of all the hosts on your network?
> 
> With one exception, I haven't personally seen a network configured in
> that way since 1998! Certainly, every network has some hosts configured
> statically, but virtually no network I've observed (and I've seen
> private networks between 2 and 50 hosts, and commercial networks between
> 5 and 30k hosts) managed completely statically.
> 

None of my networks for way over a decade have ever employed DHCP and
boy am I glad in avoiding many security issues. That was one of the
first decisions in network design I made as a teenager.

In fact the only networks that do use DHCP by definition are not well
cared for such as roaming or tethering a laptop I trust little to my
phone which I also trust little and for many good, sorry very bad mobile
network reasons.

> > 
> > As I said we would be here all day and that link wasn't as good as 
> > the one I was actually looking for.
> > 
> > local NAT done right is no problem and actually a good thing and I 
> > have no issues playing games, running servers or anything else behind
> > NAT.
> 
> See others' responses about port standardization, and about how it
> enforces a distinction between 'clients' and 'servers' that's
> unnecessary (and even harmful) for a variety of applications.
> 

Boy should there be a distinction between clients and servers, without
it we would be in a world of pain. However I still atest that there is
no problem and far less than what ipv6 advocates.

> > Global NAT works well enough
> 
> With global NAT, anything you do that depends on port forwarding is broken.
> 
> > but isn't a good thing and wouldn't exist if they had simply added 
> > more addresses quickly. The hardware uptake would have been no issue 
> > rather than a decade of pleads.
> 
> There's almost nothing you've pointed at so far that would have
> prevented backbones from IPv6 uptake...and the backbones dragged their
> heels long enough. IPv4 with expanded address bits would have been
> worse; IPv6 explicitly includes features intended to ease the strain on
> the size of a global routing view!
> 

And much more which is the problem and yet still including the bad
parts of ipv4 apparently.

> > 
> > We haven't even touched on the code yet and so all the vulnerable 
> > especially home hardware which yes often has vulnerable sps anyway 
> > but by no way just home hardware.
> > 
> > The ipvshit links give an insight into the code complexity.
> 
> You call that code complex? (and I still don't know what 'ipvshit' is,
> except possibly one guy's pejorative description of IPv6)

Think about what it is doing from the comment not the actual code.

> 
> > Note OpenBSDs kernel which is very secure (unlike Linux whose
> > primary goal is function)
> 
> I have no complaints about OpenBSD.
> 
> > and has had just a few remote holes in well over a decade, one of 
> > which was in ipv6
> 
> So OpenBSD, who you venerate, had a bug in its IPv6 implementation, and
> for that you view IPv6 as an abomination? Is that it? (Or is it because
> the guy who wrote the buggy code thinks so, and you venerate him?
> Because that seems plausible, too.)
> 

You seem to underestimate the gravity or such a bug making it into the
OpenBSD kernel.

However, not just that, try searching osvdb.org for ipv4 = < 1 page

ipv6 = > 3 pages

> > and which I had avoided without down time because I won't and what's
> >  more shouldn't use ipv6 wherever possible
> 
> Do you mean that as "I'll avoid IPv6 as much as possible" or do you mean
> that as "I won't use IPv6 in all places where it's possible to use IPv6"?
> 

Former

> If the former, I'm afraid I still haven't seen a solid technical case
> against it.
> 


> > and had actually removed it from the kernel all together.
> 
> That's sensible; if you're not going to use code, remove it.
> 

You would be surprised, many security books used to say it was a waste
of time. I ignored them.

> > 
> > If I am Trolling rather than simply trying to make people aware then 
> > stating ipv6 is wonderful is Trolling just as much or more.
> 
> IPv6 fixes things about the Internet that are currently broken by IPv4
> address exhaustion. I try to point out where IPv6 fixes things, I try to
> clear up popular misconceptions about IPv6, and I try to help people
> understand a thing rather than simply fear it.
> 
> If you take a highly competent IPv4 network administrator and drop him
> into IPv6 territory without ensuring that he has knowledge of IPv6 best
> practices and practical concerns, you're likely to get a broken network
> out of it. I try to help keep that from happening.

It is more than that. Though I am glad you are reducing the problems out
there. IPV6 unarguably is worse than IPV4. You can argue it is also
better but where if it is it serves no useful purpose for me that would
make me even consider using it unless it is redesigned.


-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

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

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 22464 bytes --]

On 03/11/2013 06:34 PM, Kevin Chadwick wrote:
>> On 03/09/2013 07:53 AM, Kevin Chadwick wrote:
>>>> "There is no reason to believe that IPv6 will result in an 
>>>> increased use of IPsec."
>>>> 
>>>> Bull. The biggest barrier to IPsec use has been NAT! If an 
>>>> intermediate router has to rewrite the packet to change the 
>>>> apparent source and/or destination addresses, then the 
>>>> cryptographic signature will show it, and the packet will be 
>>>> correctly identified as having been tampered with!
>>>> 
> 
> http://marc.info/?l=openbsd-misc&m=135325641430178&w=2

I believe you've misunderstood what Brauer is saying there.

"" NAT needs to process every packets
"
" opposed to the !NAT case, where a router doesn't have to "process"
" every packet. rrright.
"

Here, when Brauer is talking about processing, he's not talking about
tampering with (modifying) packets, he's talking about inspecting them
as part of connection state and for other things.

This is absolutely distinct from *modifying* the packet, which is what
IPsec is intended to detect. I also wouldn't count 'dropping' packets as
modification, as:

A) an intermediate firewall isn't likely to allow any packet of a stream
through to begin with if it's going to block any packet in the stream at
all.
B) Handling of dropped packets is the responsibility of the transport
layer. UDP is supposed to handle it in stride. TCP is supposed to notice
and retry.

> 
>>> 
>>> It's hardly difficult to get around that now is it.
>> 
>> Sure, you can use an IP-in-IP tunnel...but that's retarded. IPSec 
>> was designed from the beginning to allow you to do things like sign
>> your IP header and encrypt everything else (meaning your UDP, TCP,
>> SCTP or what have you).
>> 
>> Setting up a tunnel just so your IP header can be signed wastes 
>> another 40 bytes for every non-fragmented packet. Ask someone 
>> trying to use data in a cellular context how valuable that 40 bytes
>> can be.
>> 
>>> You are wrong the biggest barrier is that it is not desirable to
>>>  do this as there are many reasons for firewalls to inspect 
>>> incoming packets. I don't agree with things like central virus 
>>> scanning especially by damn ISPs using crappy Huawei hardware, 
>>> deep inspection traffic shaping rather than pure bandwidth usage
>>>  tracking or active IDS myself but I do agree with scrubbing 
>>> packets.
>> 
>> It's not the transit network's job to scrub packets. Do your 
>> scrubbing at the VPN endpoint, where the IPSec packets are 
>> unwrapped.
>> 
>> Trusting the transit network to scrub packets is antithetical to 
>> the idea of using security measures to avoid MITM and traffic 
>> sniffing attacks in the first place!
>> 
> 
> I never said it was. I was more thinking of IPSEC relaying which 
> would be analogous to a VPN end point but without losing the end-end,
> neither are desirable,

Please, explain to me what the heck you mean, then? When you say

>>> You are wrong the biggest barrier is that it is not desirable to
>>>  do this as there are many reasons for firewalls to inspect 
>>> incoming packets.

I can't possibly understand what you're talking about except with the
context you've given me.

The only other thing I can take from what you're saying up to this point
is that you believe VPNs are bad, which I find, well, laughable.

> NAT has little to do with the lack of IPSEC deployment.

You keep saying this, but saying a thing doesn't make it understood; you
have to explain why.

> 
> What do you gain considering the increased resources,

You mean the bandwidth overhead of the ESP and/or AH headers? As opposed
to, what, TLS? GRE? IP-in-TLS-in-IP?

Let me have a clean, cheap TCP-on-ESP-on-IP stack for my
campus-to-campus connections!

> pointlessly increasing chances of cryptanalysis and pointlessly 
> increasing the chances of exploitation due to the fact that the more
>  complex IPSEC itself can have bugs like Openssl does,

If I read your argument correctly, you would view encryption in general
as harmful?

> not to mention amplifying DDOS without the attacker doing anything, 
> which is the biggest and more of a threat than ever,

One of my servers is currently undergoing a SYN flood. I'm well aware
that the Internet is a dangerous place.

Honestly, if someone wants to DDOS you, the increased amplification
factor of DNSSEC isn't going to be the deciding factor of whether your
server stays up or goes down.

> or are you going to stop using the internet.

Use hyperbole much?

> When ipv4 can utilise encryption without limitations including IPSEC 
> but more appropriately like ssh just fine when needed you see it is 
> simply not desirable and a panacea that will not happen. You are 
> simply in a bubble as the IETF were.

For the purposes of tunnels, I've used IPsec on IPv4, SSH and TLS.

Quite frankly? IPsec on IPv6 is the least painful option of all of these.

IPsec on IPv4 is frustrating because the VPN clients are poorly
implemented, and you *must* use TCP/UDP-in-ESP/AH-in-(optional TCP or
UDP in)-IP, or you're not going to get through NAT without getting the
network administrator to explicitly set up a forward for you.

TLS works (and is very common for tunneling), but you're again stuck
with whatever-in-IP-in-TLS-in-TCP/UDP-in-IP. Or, more commonly,
whatever-in-IP-in-Ethernet-in-TLS-in-TCP/UDP-in-IP. I'd be amazed if you
didn't think that was a royal mess.

SSH for tunneling? *Royal* PITA, especially when you have to connect to
multiple places at once. If all you have is one endpoint you have to
connect to to get where you're going, you can use SOCKS. Otherwise,
you're forwarding ports. If you're forwarding ports, you're OK, so long
as you don't have to use the same local port for two different purposes.
And, yes, I've *seen* setups so convoluted that there were explicit
instructions stating which local port would have to be used for each
remote service, with server-side accommodations to suit, simply so that
those local ports wouldn't conflict.

With IPsec on IPv6, in *all* of the circumstances where I've required a
VPN, the setup would have been a clean (whatever)-in-ESP/AH-in-IP. That
would be *much* cleaner, and *much* more efficient at all levels of the
network.

> 
>>> 
>>>> With IPsec, NAT is unnecessary. (You can still use it if you 
>>>> need it...but please try to avoid it!)
>>>> 
>>> 
>>> Actually it is no problem at all and is far better than some of 
>>> the rubbish ipv6 encourages client apps to do. (See the links I 
>>> sent in the other mail)
>> 
>> Please read the links before you send them, and make specific 
>> references to the content you want people to look at. I've read and
>> responded to the links you've offered (which were links to archived
>> messages on mailing lists, and the messages were opinion pieces
>> with little (if any) technical material.)
>> 
> 
> 
>>> 
>>>> Re "DNS support for IPv6"
>>>> 
>>>> "Increased size of DNS responses due to larger addresses might
>>>>  be exploited for DDos attacks"
>>>> 
>>>> That's not even significant. Have you looked at the size of DNS
>>>> responses? The increased size of the address pales in 
>>>> comparison to the amount of other data already stuffed into the
>>>> packet.
>>> 
>>> It's been ages since I looked at that link and longer addresses 
>>> would certainly be needed anyway but certainly with DNSSEC again 
>>> concocted by costly unthoughtful and unengaging groups who chose
>>> to ignore DJB and enable amplification attacks.
>> 
>> What from DJB did they ignore? I honestly don't know what you're 
>> talking about.
>> 
> 
> They completely ignored dnscurve.org

You know, I managed to read up on DNSCurve thanks to the link Michael
Orlitzky provided, and you know what I think of it?

I think it would do more harm to the DNS infrastructure than good. The
implementation advocated would disallow intermediary DNS servers, and
that is a *very bad thing*, because it disallows caching.

Caching isn't just about being able to get a response to the client
quickly. It's also about being able to get a response to the client *at
all*.

By default, a DNS resolver will make a query, wait 30s for a timeout,
retry their query, wait significantly longer for a timeout, and then try
a third time while waiting significantly longer.

If the resolver's query reaches the DNS server fine, and the DNS
server's response reaches the resolver fine, all is well. If the query
or response packets get lost along the way, then the resolver (which is
probably someone's web browser) waits 30s before it tries again. 30s is
a *long* time. Your average user will only wait 10s before hitting F5 or
moving along.

Now, consider a typical modern residential network:

{( internet )} -> ISP -> ADSL -> home router -> end user.

That ADSL link is an absolutely treacherous beast. It drops packets
without mercy, and the more you can accomplish without having to send
packets across it, the better. Unfortunately, your average modern
website includes files from up to a dozen different domains, with a few
redirections involved for most of them.

The typical modern home router has a caching DNS server built-in because
DNS commonly operates over UDP, and UDP does not provide delivery
guarantee. The end user's resolver (which is in their web browser)
queries the home router, which then recurses and makes the query of the
upstream servers on the end-user's behalf. Once the recursive resolver
gets a response, it caches that response.

I use a Debian PC as my home router. When I was on DSL, I initially
didn't set up a caching recursive resolver. (I also didn't have caching
recursive resolvers installed locally on my machines.) The Internet felt
terrible. Half the resources on any given social media site or complex
web page didn't load until the second or third refresh, simply because
the DNS requests to find the relevant servers got lost along the way.

Once I set up a caching recursive resolver on my router, my Internet
experience improved dramatically.

Now consider a more painful (yet still typical) network:

{( internet )} -> ISP -> ADSL -> wifi hot spot -> end user

That wifi hot spot hammers packets harder than the ADSL link that's also
taking its due. Between having too many APs in a given area, too many
clients on a public network and too much ambient noise in the 2.4GHz ISM
band, getting a packet through that network is like playing frogger
blind; you only accomplish it because your computer plays the game with
infinite lives and doesn't let you see all the times the frog got squished.

This is why all Windows systems have had caching recursive resolvers
built-in for years, and why NetworkManager likes to use dnsmasq; you've
added caching to local systems to work around terrible local physical
layers.

Do we need to get into using cellular connections and tethering in
non-urban areas? I could tell you about a six-mile stretch on my wife's
daily commute that the phone claims to have data service in, but can't
get a packet through to save its battery.

> or that RSA768 was not strong enough to be a good choice

I don't think many people seriously anticipated how rapidly Moore's law
would catch up with public-key cryptography. I'm not sure *anybody*
without security clearance or heavy NDAs could have anticipated it using
any sane series of logic.

> and ECDSA should be looked at and most importantly the DOS 
> amplification (we are talking years ago).

I understand that this is a key issue for you. I can't comprehend why,
as I can't see why it's as significant an issue as you seem to believe
it to be.

> I even had a discussion with a dns caching tools (that I do like a 
> lot) author who completely dismissed the potential of RSA being 
> broken for years and years. Guess what's come to light since.

As I said, Moore's law managed to surprise a great number of very
reasonable people. There's *no* way that anyone in  1995 could have
reasonably anticipated the rise of fully-programmable
mass-parallel-calculation engines whose development was driven and made
cheap (and thus highly, highly scaleable) by *video games*.

> 
>>> 
>>> His latest on the "DNS security mess"
>>> 
>>> http://cr.yp.to/talks/2013.02.07/slides.pdf
>> 
>> I've never before in my life seen someone animate slideshow 
>> transitions and save off intermediate frames as individual PDF 
>> pages. That was painful.
>> 
> 
> Yeah, xpdf worked well though. I actually couldn't find the link and
>  looked it up and thought it was just an update of 2012 as it had the
>  same title and only got around to reading it about an hour later.
> 
>> So, I read what was discussed there. First, he describes failings 
>> of HTTPSEC. I don't have any problem with what he's talking about 
>> there, honestly; it makes a reasonable amount of sense,
>> considering intermediate caching servers aren't very common for
>> HTTP traffic, and HTTPS traffic makes intermediate caching
>> impossible. (unless you've already got serious security problems by
>> way of a MITM opening.)
>> 
>> Then he turns around and dedicates two slides showing a DNS 
>> delegation sequence...and then states in a single slide that DNSSEC
>> has all the same problems as HTTPSEC.
>> 
>> DNSSEC doesn't have the same problems as HTTPSEC, because almost 
>> *every* recursive resolving DNS server (which is most of the DNS 
>> servers on the Internet) employs caching.
>> 
> 
> I suggest you read the 2012 slides.

Provide me with a link, and I will. I'm not going to go digging without
a strong idea of what I'm looking for, and where to find it.

> 
>>> 
>>>> "An attacker can connect to an IPv4-only network, and forge 
>>>> IPv6 Router Advertisement messages. (*)"
>>> 
>>>> Again, this depends on them being on the same layer 2 network 
>>>> segment.
>>> 
>>>> The same class of attacks would be possible for any IPv4 
>>>> successor that implemented either RAs or DHCP.
>>> 
>>> Neither of which I use.
>> 
>> You're telling me you don't use DHCP? Seriously, that you 
>> statically configure the IPv4 addresses of all the hosts on your 
>> network?
>> 
>> With one exception, I haven't personally seen a network configured
>>  in that way since 1998! Certainly, every network has some hosts 
>> configured statically, but virtually no network I've observed (and
>>  I've seen private networks between 2 and 50 hosts, and commercial
>>  networks between 5 and 30k hosts) managed completely statically.
>> 
> 
> None of my networks for way over a decade have ever employed DHCP
> and boy am I glad in avoiding many security issues. That was one of
> the first decisions in network design I made as a teenager.
> 
> In fact the only networks that do use DHCP by definition are not
> well cared for such as roaming or tethering a laptop I trust little
> to my phone which I also trust little and for many good, sorry very
> bad mobile network reasons.

You're pretty much in a class of your own, there. I'm sorry to say I
can't empathize or agree in the slightest...

> 
>>> 
>>> As I said we would be here all day and that link wasn't as good 
>>> as the one I was actually looking for.
>>> 
>>> local NAT done right is no problem and actually a good thing and
>>>  I have no issues playing games, running servers or anything else
>>>  behind NAT.
>> 
>> See others' responses about port standardization, and about how it 
>> enforces a distinction between 'clients' and 'servers' that's 
>> unnecessary (and even harmful) for a variety of applications.
>> 
> 
> Boy should there be a distinction between clients and servers, 
> without it we would be in a world of pain.

Why? You keep making statements without giving reasons for them.

> However I still atest that there is no problem and far less than
> what ipv6 advocates.

Are you referring to the problems identified by the slides you've
referenced so far? And that I've largely addressed, debunked or pointed
out are no worse than IPv4? You never gave me a point-by-point
response...instead you indicated the slide deck wasn't as good as the
one you were looking for. Apart from your finding any dynamic network
configuration appalling, I don't know what you're talking about.

> 
>>> Global NAT works well enough
>> 
>> With global NAT, anything you do that depends on port forwarding is
>> broken.
>> 
>>> but isn't a good thing and wouldn't exist if they had simply 
>>> added more addresses quickly. The hardware uptake would have been
>>> no issue rather than a decade of pleads.
>> 
>> There's almost nothing you've pointed at so far that would have 
>> prevented backbones from IPv6 uptake...and the backbones dragged 
>> their heels long enough. IPv4 with expanded address bits would have
>> been worse; IPv6 explicitly includes features intended to ease the
>> strain on the size of a global routing view!
>> 
> 
> And much more which is the problem

Wait, what? No!

I'm talking about route aggregation, which comes in part from the use of
CIDR notation. Through route aggregation, you reduce the number of
entries in the routing table. Yes, the byte size of the global routing
view will grow with IPv6. IPv4 with 128 address bits would have been far
worse, unless route aggregation was made part of its design (as was done
with IPv6).

> and yet still including the bad parts of ipv4 apparently.

Are there any parts of IPv4 that IPv6 carries that you consider bad
parts, or are we just talking about DHCP again?

> 
>>> 
>>> We haven't even touched on the code yet and so all the vulnerable
>>> especially home hardware which yes often has vulnerable sps
>>> anyway but by no way just home hardware.
>>> 
>>> The ipvshit links give an insight into the code complexity.
>> 
>> You call that code complex? (and I still don't know what 'ipvshit'
>>  is, except possibly one guy's pejorative description of IPv6)
> 
> Think about what it is doing from the comment not the actual code.

You mean this seemingly harmless comment?

/*
 * sin6_len is the size of the sockaddr so substract the offset of
 * the possibly truncated sin6_addr struct.
 */

Or do you mean this advocacy of NAT444

" who sez that your made up isp has to hand out network-wide unique IPs
" to his customers?

This attack on the person he's replying to:

" why do i even waste time on some ipvshit advocate that acts like a
" politician claiming we have to eat shit because there wouldn't be an
" alternative, making up a case out of nothing to "prove" his case?

Or his diatribe about IPv6?

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

I'm not seeing what I've misinterpreted.

> 
>> 
>>> Note OpenBSDs kernel which is very secure (unlike Linux whose 
>>> primary goal is function)
>> 
>> I have no complaints about OpenBSD.
>> 
>>> and has had just a few remote holes in well over a decade, one of
>>> which was in ipv6
>> 
>> So OpenBSD, who you venerate, had a bug in its IPv6 implementation,
>> and for that you view IPv6 as an abomination? Is that it? (Or is it
>> because the guy who wrote the buggy code thinks so, and you
>> venerate him? Because that seems plausible, too.)
>> 
> 
> You seem to underestimate the gravity or such a bug making it into 
> the OpenBSD kernel.

You seem to labor under the misunderstanding that OpenBSD is perfect.

> 
> However, not just that, try searching osvdb.org for ipv4 = < 1 page
> 
> ipv6 = > 3 pages

You know what I'm noticing in those three pages? Most of those bugs are
in hardware vendor firmware. I don't think it would have been any better
if they'd had to implement a "IPv4 with extended address bits" protocol.
Say what you want about IPv6 being complex, the truth is that IPv6 was
explicitly designed to simplify and streamline packet routing.

> 
>>> and which I had avoided without down time because I won't and 
>>> what's more shouldn't use ipv6 wherever possible
>> 
>> Do you mean that as "I'll avoid IPv6 as much as possible" or do you
>> mean that as "I won't use IPv6 in all places where it's possible to
>> use IPv6"?
>> 
> 
> Former
> 
>> If the former, I'm afraid I still haven't seen a solid technical 
>> case against it.
>> 
> 
> 
>>> and had actually removed it from the kernel all together.
>> 
>> That's sensible; if you're not going to use code, remove it.
>> 
> 
> You would be surprised, many security books used to say it was a 
> waste of time. I ignored them.
> 
>>> 
>>> If I am Trolling rather than simply trying to make people aware 
>>> then stating ipv6 is wonderful is Trolling just as much or more.
>> 
>> IPv6 fixes things about the Internet that are currently broken by 
>> IPv4 address exhaustion. I try to point out where IPv6 fixes 
>> things, I try to clear up popular misconceptions about IPv6, and I
>>  try to help people understand a thing rather than simply fear it.
>> 
>> If you take a highly competent IPv4 network administrator and drop
>>  him into IPv6 territory without ensuring that he has knowledge of
>>  IPv6 best practices and practical concerns, you're likely to get a
>>  broken network out of it. I try to help keep that from happening.
> 
> It is more than that. Though I am glad you are reducing the problems
>  out there.

I want to highlight this next bit.

> IPV6 unarguably is worse than IPV4. You can argue it is 
> also better

...

> but where if it is it serves no useful purpose for me 
> that would make me even consider using it unless it is redesigned.

I can't say nobody is going to force you to use IPv6. That would be a
lie. Eventually, there will be services on the Internet which you won't
be able to access without using IPv6 in some way.

It's far better to learn how to use the thing (better still, learn how
to use it properly!) than to get pushed deeper into the pool without
first learning how to swim.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]

Am 08.03.2013 01:29, schrieb Michael Mol:
> On 03/07/2013 05:24 PM, Alan McKinnon wrote:
>> Anyone know if there's a way to get /etc/hosts to support the notion of
>> an include file? I did my homework and found nothing, maybe someone else
>> knows more.
>>
>> I really do need this, I have an app that discovers things on the
>> network and knows their address. This makes it's automated way into DNS
>> but takes a few days, and another app needs to use the fqdn right now.
>> So /etc/hosts is the way to go for the interim three days.
>>
>> I've worked around it by creating /etc/hosts.d/ containing a header and
>> a data file. cat the two and redirect to /etc/hosts.d/hosts and the real
>> hosts file is a symlink to that. It's a sub-directory as none of these
>> apps run as root and only root can modiy the real hosts file.
>>
>> This works well enough, but a supported include mechanism would make
>> life so much simpler, not to mention easier for my colleagues to
>> understand what the blazes I set up :-)
> 
> No, there's not an "include" directive.
> 
> There are, however, two other ways to get hostnames recognized.
> 
> The first is /etc/resolv.conf . You can point your host at a local DNS
> server which is aware of the discovered hosts, and which forwards the
> rest of the queries. (This is how Samba 4's internal DNS server
> operates; anything it knows, it responds to. Everything else, it forwards.)
> 

dnsmasq also works like this and is probably easier to set up. FWIW it
also supports include files.

Regards,
Florian Philipp



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

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

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 1445 bytes --]

On Mar 8, 2013 5:27 AM, "Alan McKinnon" <alan.mckinnon@gmail.com> wrote:
>
> Anyone know if there's a way to get /etc/hosts to support the notion of
> an include file? I did my homework and found nothing, maybe someone else
> knows more.
>
> I really do need this, I have an app that discovers things on the
> network and knows their address. This makes it's automated way into DNS
> but takes a few days, and another app needs to use the fqdn right now.
> So /etc/hosts is the way to go for the interim three days.
>
> I've worked around it by creating /etc/hosts.d/ containing a header and
> a data file. cat the two and redirect to /etc/hosts.d/hosts and the real
> hosts file is a symlink to that. It's a sub-directory as none of these
> apps run as root and only root can modiy the real hosts file.
>
> This works well enough, but a supported include mechanism would make
> life so much simpler, not to mention easier for my colleagues to
> understand what the blazes I set up :-)
>
>
>
> --
> Alan McKinnon
> alan.mckinnon@gmail.com
>
>
>

An option would be to create a cron job which generates the hosts file
every minute. The cron job should also insert a header on top of the hosts
file telling:

+ this file (hosts) is dynamically generated
+ by a system cron job
+ the cron job's script location

Besides, you said you're going to need this workaround only for a couple of
days, so installing Samba4 might be an overkill.


Rgds,
--

[-- Attachment #2: Type: text/html, Size: 1864 bytes --]

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

[Alan McKinnon]

On 08/03/2013 06:30, Pandu Poluan wrote:
> 
> On Mar 8, 2013 5:27 AM, "Alan McKinnon" <alan.mckinnon@gmail.com
> <mailto:alan.mckinnon@gmail.com>> wrote:
>>
>> Anyone know if there's a way to get /etc/hosts to support the notion of
>> an include file? I did my homework and found nothing, maybe someone else
>> knows more.
>>
>> I really do need this, I have an app that discovers things on the
>> network and knows their address. This makes it's automated way into DNS
>> but takes a few days, and another app needs to use the fqdn right now.
>> So /etc/hosts is the way to go for the interim three days.
>>
>> I've worked around it by creating /etc/hosts.d/ containing a header and
>> a data file. cat the two and redirect to /etc/hosts.d/hosts and the real
>> hosts file is a symlink to that. It's a sub-directory as none of these
>> apps run as root and only root can modiy the real hosts file.
>>
>> This works well enough, but a supported include mechanism would make
>> life so much simpler, not to mention easier for my colleagues to
>> understand what the blazes I set up :-)
>>
>>
>>
>> --
>> Alan McKinnon
>> alan.mckinnon@gmail.com <mailto:alan.mckinnon@gmail.com>
>>
>>
>>
> 
> An option would be to create a cron job which generates the hosts file
> every minute. The cron job should also insert a header on top of the
> hosts file telling:
> 
> + this file (hosts) is dynamically generated
> + by a system cron job
> + the cron job's script location
> 
> Besides, you said you're going to need this workaround only for a couple
> of days, so installing Samba4 might be an overkill.



I'm already doing something very much like that, I reckon I'll leave it
in place, and document it in the grand CYA tradition.

To be clear, it's not a temporary workaround - it's permanent. I do
network discovery every 12 hours and can find up to 7000 things on the
network, so now I know their hostname and address. This eventually makes
it's way into DNS, but DNS by design updates slowly and a second app (an
audit app) needs to resolve the names immediately. That's why hosts is
the perfect interim solution; in 3 days when the DNS update happens the
entry is removed from the hosts file.



-- 
-- 
Alan McKinnon
alan.mckinnon@gmail.com