[arin-ppml] Set aside round deux
Roger Marquis
marquis at roble.com
Thu Aug 5 16:18:08 EDT 2010
> Yes, a NAT box cannot function without stateful inspection. However, that
> does not mean that a NAT box is a firewall.
By the same logic a tcp firewall can function without udp or icmp. In
the real world, however, you don't see such implementations.
>> * If you can explain how multihoming will work without NAT and without
>> internal renumbering then please do. If you think internal renumbering
>> is feasible please explain how to maintain persistent connections across
>> a renumbering?
>>
> Once again, I will endeavor to explain this to you:
>
> If you are multihomed, you can get global unicast addresses directly from
> your RIR and advertise them to your upstreams, just like multihoming is
> supposed to work in IPv4. No NAT required, no super special secret
> technology.
Please Owen, you know what I'm talking about, not theoretical multihoming
but the real world stuff, where internal clients have a single IP and a
single default route that doesn't change, without localhost
accommodations (ie., points of failure) of any kind.
>> * How to would you do transparent load-balancing and fail-over, ingress
>> or egress, without NAT?
>>
> Again, I will endeavor to explain this to you:
>
> Border Ingress and Egress -- BGP is fairly good at this. At least as good
> as any of the cobbled IPv4 NAT solutions I am aware of.
This assumes all upstreams will always route foreign source addresses
from your link, also not sustainable in most real-word implementations.
> I really don't understand why you keep equating GUA with upstream lock-in.
In ARIN-PPML GUA has been used to mean every end-node is mapped
externally i.e., your network connectivity is dependent on upstreams
knowing about, having routes for, maintaining routing for, and dampening
routes for, your internal hosts at their discretion, not yours. Not just
your gateways, but your internal hosts. Not just some of them either,
but all of them.
> Please explain to me how getting a prefix from ARIN locks you into any
> particular upstream because I simply am not understanding this argument.
Please explain the return for end-users of adding ARIN as a point of
failure? Come on Owen, these are purely rhetorical arguments without
technical merit, without a reasonable business case, and with negative
ROI.
>> * How would you deal with routing table growth in absence of NAT?
>>
> NAT doesn't reduce route table growth. NAT reduces address consumption.
Ok, no routing table growth. Would love to see your math.
Such is the case against NAT i.e., purely rhetorical. So rhetorical in
fact that most engineers I know consider them proof of an agenda. To
find that agenda follow the money to several animated discussions of the
post-exhaustion address market in NANOG and other mailing list archives.
I believe economists call this "pump and dump".
Roger Marquis
More information about the ARIN-PPML
mailing list