3 ms·

You've heard it before, but for the sake of balancing your comment on NAT... Sincerly and honestly: NAT does not solve anything that a firewall (6 lines of ip6t

You've heard it before, but for the sake of balancing your comment on NAT... Sincerly and honestly: NAT does not solve anything that a firewall (6 lines of ip6tables rules) - or stopping that unecessary service - doesn't. All it does is create two classes of network devices (and netizens): those that can talk directly and those who depend on a third party. There's no reason not to have a global address anymore, even if you don't expect to use it. Even something as simple as putting a firewall appliance in the middle is the wrong approach. Logic needs to be near the edge, in the host IMHO; by putting any rules in the middle (firewall, NAT, QoS), other than the basic routing, one loses the intended ability to dial direct in unanticipated scenarios tomorrow (for example, to run a new service without touching every hop between A and B because of dozens of attempts to "make it better" at that hop). IMHO NAT really is an example of our eagerness to hang ourselves, given enough rope.

ghshephard 13y ago
Good balance - and certainly it's a common refrain from those who are architecting and writing RFCs. And, keep in mind, 100% of all corporate networks I've seen with NAT, also have (typically very expensive) firewalls with highly restrictive rules. But corporate IT stooges (which I've certainly played the roll of) will say: "Here is what NAT will do for you with IPv6" #1 - You don't expose any internal hosts addresses to the external world, everything comes from a single external host. #2 - No route back to the hosts inside the lan. If they can't route to you, they can't attack you. (Not really true, but it does make it more challenging to mount an attack from the Outside -> In. ) #3 - You can change ISPs without any internal renumbering required. Unlike with IPv4, getting provider-independent IPv6 space can be challenging. IPv6-to-IPv6 Network Prefix Translation (NPTv6) might be a happy middle ground that solves #3, but still leaves you mostly exposed on #1 and #2.
- vy8vWJlco 13y ago
  I'm still vehement that #1 & #2 are wishful thinking (security through obscurity... better to drop all packets, or simply not use a public address; ULAs are fine IMHO), but perhaps something as simple as a prefix-aliasing notation would allow easier internal referencing and address #3. For example, MY_NETWORK:1. That can be done with shell/environment variable substitutions before using them, but it would be nice to be able to count on IPv6 applications to accept something like that for networks in the routing table... (might require a prefix-naming RFC, so a name can come with a router/prefix advertisement and/or the ability to store name-to-network prefix mappings in DNS SRV, or similar, allowing internal or global users to find the right host on the right network...) That said, truly global addresses with service registries like DNS/mDNS, etc, remove the need for immutable (staticly-assigned and hard-coded) addresses entirely, albeit at the expense of registration and lookup.

ghshephard 13y ago

Good balance - and certainly it's a common refrain from those who are architecting and writing RFCs. And, keep in mind, 100% of all corporate networks I've seen with NAT, also have (typically very expensive) firewalls with highly restrictive rules. But corporate IT stooges (which I've certainly played the roll of) will say: "Here is what NAT will do for you with IPv6" #1 - You don't expose any internal hosts addresses to the external world, everything comes from a single external host. #2 - No route back to the hosts inside the lan. If they can't route to you, they can't attack you. (Not really true, but it does make it more challenging to mount an attack from the Outside -> In. ) #3 - You can change ISPs without any internal renumbering required. Unlike with IPv4, getting provider-independent IPv6 space can be challenging. IPv6-to-IPv6 Network Prefix Translation (NPTv6) might be a happy middle ground that solves #3, but still leaves you mostly exposed on #1 and #2.

vy8vWJlco 13y ago
I'm still vehement that #1 & #2 are wishful thinking (security through obscurity... better to drop all packets, or simply not use a public address; ULAs are fine IMHO), but perhaps something as simple as a prefix-aliasing notation would allow easier internal referencing and address #3. For example, MY_NETWORK:1. That can be done with shell/environment variable substitutions before using them, but it would be nice to be able to count on IPv6 applications to accept something like that for networks in the routing table... (might require a prefix-naming RFC, so a name can come with a router/prefix advertisement and/or the ability to store name-to-network prefix mappings in DNS SRV, or similar, allowing internal or global users to find the right host on the right network...) That said, truly global addresses with service registries like DNS/mDNS, etc, remove the need for immutable (staticly-assigned and hard-coded) addresses entirely, albeit at the expense of registration and lookup.