All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ed W <lists@wildgooses.com>
To: "Krzysztof Olędzki" <ole@ans.pl>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: NAT66 : A first implementation
Date: Sun, 17 Jul 2011 23:23:05 +0100	[thread overview]
Message-ID: <4E2360C9.20304@wildgooses.com> (raw)
In-Reply-To: <4E226E7D.6050800@ans.pl>

Hi

> How would you imagine managing and maintaining a typical corporate
> network (1K+ devices) of different devices and operating systems -
> workstations (Windows, Mac, Linux), servers (Windows, Linux, BSD)
> routers, switches (radius), firewalls, APs, etc; without static IP
> addresses? Static = not random.

I agree.  Can't see how you would (unless dynamic DNS started to work a
whole lot better than today...)


> Also, how would you imagine readressing such network one day, when you
> decide to change your ISP?

Aha.  This is a statement that you don't believe PI space will become
easier to access when requesting IPV6 space?

There seems to be sufficient space for PI to become the norm to hand
out.  However, the current state of routing appears to struggle with
IPV4 taken to the limit, and so there seems to be understandable
reluctance to actually fix all the issues we have with IPV4 since some
facets of the solution kill current routing hardware..?

Mobile phone numbers are now interchangeable between phone companies in
under 24 hours in the UK.  Lets hope that PI space allocations become
the norm under IPv6..?


> Without NAT (and BTW without working and complete L3 security in
> switches) no one will consider IPv6 seriously nor dare to implement it
> in production. Of course NAT does not provide security but it provides a
> real and useful privacy, opposite to annoying randomness.

It's not clear to me that NAT solves L3 security any better than a
non-nat firewall?  "Security" through NAT is largely through breaking
routing, but a non NAT firewall appears to achieve entirely the same
effect more directly (some would argue much better in fact)


I personally think that IPV6 NAT could be very useful for a number of
niche situations!  Please lets see this get implemented!

On the other hand I hope that widespread adoption doesn't happen...
Instead I hope that PI allocations become straightforward and the norm.
I would also disagree with some of the reasons *why* you want NAT,
although at the limit I would still agree NAT is useful for some
situations (just different situations)

Cheers

Ed W

  reply	other threads:[~2011-07-17 22:30 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-14 15:47 NAT66 : A first implementation Terry Moës
2011-07-14 16:22 ` Jan Engelhardt
2011-07-14 16:27   ` Terry Moës
2011-07-14 23:15     ` Jan Engelhardt
2011-07-14 23:17       ` David Miller
2011-07-14 23:37         ` Rick Jones
2011-07-15 15:43           ` Rick Jones
2011-07-14 23:55         ` Jan Engelhardt
2011-07-17  5:09           ` Krzysztof Olędzki
2011-07-17 22:23             ` Ed W [this message]
2011-07-17 23:54               ` Krzysztof Olędzki
2011-07-18  8:38                 ` Ed W
2011-07-15  0:48         ` Jeff Haran
2011-07-15  2:29           ` Adam Roach
2011-07-15 22:12             ` Jeff Haran
2011-07-16  3:08               ` Adam Roach
2011-07-18  2:05         ` YOSHIFUJI Hideaki
2011-07-18 15:50         ` Patrick McHardy
2011-07-21  7:15           ` Harald Welte
2011-07-15  5:48       ` Philip Craig
2011-07-15 10:29         ` Jan Engelhardt
     [not found]       ` <4E20051D.7080208@student.ulg.ac.be>
2011-07-15  9:16         ` Terry Moës
2011-07-15 11:09           ` Jan Engelhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E2360C9.20304@wildgooses.com \
    --to=lists@wildgooses.com \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=ole@ans.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.