Operational challenges of no NAT
Ted Mittelstaedt
tedm at ipinc.net
Sat Oct 30 08:54:17 CEST 2010
On 10/29/2010 8:27 PM, John Payne wrote:
>
>
> On Oct 29, 2010, at 6:45 PM, Ted Mittelstaedt<tedm at ipinc.net>
> wrote:
>> Certainly. You get it exactly the same way you get it WITH nat.
>
> Your experience running an enterprise network seems to be very
> different from my own and the people you love to tell "you don't need
> NAT". Perhaps if you gave an overview of your network, it would help
> those of us struggling with where the least worst place to lose some
> simplifications that NAT44 provides are.
>
>> If you don't have PI then what people mean by "provider
>> independence" is nothing more than "It's easier to renumber when I
>> move to a different provider"
>
> And I can have a coherent "internal" addressing scheme even with
> different Internet providers at each of my "many" offices.
>
Unless your VPNing them together why would you care?
>>
>> It doesn't mean "I have my own IP address block assigned by an RIR
>> and I can move it around"
>
> Yes, otherwise I'd have PI space.
>
>>
>> If you are NAT and you move then you still have to change all the
>> DNS stuff to point to the "new" outside IP address, and you have to
>> change your NAT maps and anyone who is VPNed into you, etc. etc.
>
> In the "remote" offices, I don't care about any of that.. Im just
> NATing users. No VPN, maybe one DNS entry, and one interface on the
> NAT box (it's on a firewall, but I don't think of NAT as privacy or
> security)
>
>
>> Under IPv6 that isn't any different.
>
> Sure it is
>
>>
>> You do NOT have to turn your renumbering into a complete
>> cluster-fuck like it is under IPv4. Please, read the docs. You
>> can start here:
>>
>> http://www.getipv6.info/index.php/Renumbering_an_IPv6_Network
>
> Yeah, that works great for a single homed, no server network. What
> about a multi homed office? Multiple addresses on all end devices
> simply shifts cost control too far away from the network admins. It
> also mentions nothing about internal ACLs and firewall policies that
> would have to be updated.
>
>>
>>> Multihoming is even worse. On top of all of the provider
>>> independence requirements, add the ability to decide *in the
>>> network* which upstream any outbound connection goes through,
>>> using only protocols available today. I understand there are
>>> protocols in the pipeline to make hosts more intelligent about
>>> source address selection, but (a) you're still relying on the
>>> host to make that decision, something that's really network-level
>>> knowledge, and (b) there's no way those protocols can encompass
>>> every criterion people could want to make decisions on. With v4
>>> NAT, I can round-robin all port 80 connections out providers A
>>> and B, and send all other traffic out provider C. There is no way
>>> to do that with no-nat v6.
>>>
>>
>> That is a true statement ONLY IF you ASSUME THAT IPv6 NAT IS ONE TO
>> ONE.
>>
>> The problem here is that all of the other IPv6-NAT advocates DO
>> NOT WANT one-to-one IPv6 NAT. They understand NAT to be
>> many-to-one. In short, they do not want what you need to keep this
>> load-balancing hack running.
>
> Wrong. You are just so hot to shoot down anyone even thinking that
> NAT has uses that you dont appear to be listening to use cases. 1:1
> NAT66 is exactly what I want
No it isn't. You want TWO NAT66 boxes, one for each upstream feed,
somehow mangled together to get this load balancing thing your
talking about.
Here is my suggestion. Why don't you and the other pro-NAT folks
get together and take up the BusyBox Linux NAT66 code here:
http://ipv6.bupt.edu.cn/nat66/
and pay some developer to create this NAT66 load-balancing
black box? The code is already ready to run on a small SOHO
router. Build the thing and it will be so great that everyone
will start using it, and Bang, you got a de-facto standard for
IPv6 NAT. That's exactly how IPv4 NAT started up. They
built a NAT box on KA9Q and on a Cray router BEFORE they wrote
RFC1631
The site isn't up right this moment but it comes and goes.
> and what I've seen others ask for.
>
Are you seriously claiming that everyone out there who has
(in your words) "...many...remote...multi homed offices" is running this
load balancer black box that round-robins outbound packets?
How many SOHO "remote" offices out there generate sufficient traffic
that round-robin load balancing does anything? Very few. That sort of
"load balancing" only has one use - when there are a lot of endpoints
out there that a site is sending data to. Such as a content provider.
But a "remote" office that is sourcing a lot of traffic is usually
doing it to the mothership (such as a file copy) or e-mail transfer or
other such thing. In which case the black-box under discussion is
useless since it is using multiple public source IP addresses it cannot
split a TCP connection over the outbound feeds the way a real PI number
that is being advertised to multiple providers can. (since in that
instance all the traffic originates from a single IP)
>
>
>>
>> You simply need a load balancer that takes a subnet of IPv6 from
>> each provider, and does one-to-one IPv6 NAT. In even the smallest
>> IPv6 subnets there is plenty of IP numbers so every one of your
>> inside hosts can have it's own unique IPv6 address with each
>> provider.
>
> Simple question. If multiple PA addresses and renumbering is so
> simple, why is Cisco running PI on their v6 Internet presence?
Because they are big enough to get it and because they obviously have a
website that scads of people are pulling data off of simultaneously. PI
space allows them to split a single TCP data stream to a remote end user
over all of their feeds, if necessary. NAT66 does not allow
this.
In the larger context, though,
I think your interpreting my points against NAT as somehow also
supporting raising the bar for an org to get PI space. That isn't true
nor have I attempted to link the two.
In a perfect world everyone who wanted to multihome would get PI
space and their own AS and advertise it. The DFZ would be huge and
routers would be lightning fast and could handle a DFZ that occupied
3-4 gigabytes of ram. (or however much it took)
But in the world we have, we have smaller orgs who cannot qualify
for PI space wanting to multihome and complaining that the bar is too
high for them to get PI space. And at the same time they are
complaining because IPv6 is making them spend money on getting new
routers that support it. There is a basic disconnect here. In
other words, these small orgs want to continue to run cheap, old
routers but they also want to advertise their own AS and flood the
DFZ - thus making it bigger - thus requiring bigger and more expensive
routers. The irony is obvious.
Ted
More information about the ipv6-ops
mailing list