RE: Stupid NAT tricks and how to stop them.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Tim Chown wrote:
> If you deploy IPv6 NAT, you may as well stay with IPv4.

Tim,

You're the one who convinced me some three years ago that there will be
IPv6 NAT no matter what, what's the message here?
 
> See also
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-02.txt

Remember: Users don't read drafts/RFCs.


> We have deployed IPv6 in our enterprise (throughout).

Could you have done it if you did not have the
research dollars^H^H^H^H pounds?



> Artur Hecker wrote:
> the (static) statement that "90% of phones are
> analog" seems very wrong to me.

My bad, I should have said land lines.


> Hallam-Baker, Phillip wrote:
> I have never seen a coherent, rational argument as to why
> the network numbering on my internal network should be the
> same as the network numbering on the Internet.

Phillip, there a few (such as: NAT typically requires hard state, which
is a pain to replicate if there is more than one edge router). NAT is
not completely evil, but it's far from being clean. Pretending that
there are no good reasons against NAT is going to achieve the same as
trying to eliminate it: nothing.


> People will still want to do NAT on IPv6.

Yes, and since site-locals have been deprecated they will also hijack an
unallocated block of addresses to use as private, same what happened
prior to RFC 1597 for the very same reasons (difficult/pricey to get
PI).


> Austin Schutz wrote:
> ...that opportunity may be to enhance NAT rather than throw it away

Austin, this has been tried many times and never went anywhere. As there
are no changes in the reasons it has failed in the past I don't see how
this could make it this time.


>> Michel Py wrote:
>> A protocol that would be only v4 with more bits in the first place, 
>> with routers / NAT boxes that would pad/unpad extra zeroes (also 
>> including extra TBD fields). As this would be 100% compatible with v4

>> this could be deployed without too many headaches.

> Keith Moore wrote:
> huh?  there is no way to make a protocol that can address more hosts
> than v4, that is 100% compatible with v4.  and there's no good way to
> divide up the net into v4 enclaves and v6 enclaves because the
> applications that need v6 addressing don't fit neatly into enclaves.

As long as you don't use the extra bits, no problem. IPv4 on one side,
IPv4+ on the other; when going from v4 to v4+ add a bunch of zeroes,
when going to v4+ to v4 remove a bunch of zeroes. Initially it's a total
waste of bits, but silicon is cheap these days.

When people will begin to scream bloody murder to use the extended bits
(because v4 is getting near exhaustion) the infrastructure could be
already in place, and then the pressure will be on software developers
to recode their stuff with 128-bit addresses. When that has happened,
then we can make use of all these reserved fields for better purposes,
and possibly allocate PI to everybody which is another pre-requisite to
get rid of NAT.

Michel.


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]