Re: why IPv6 is bad, No, SMTP is IPv4, Was: SMTP and IPv6

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

 



On 04-Jul-24 00:05, Phillip Hallam-Baker wrote:
So, about defeating traffic analysis...

I really don't understand why there is this fetish for keeping the IP address the same from endpoint to endpoint.

It really isn't a fetish, it's an operational challenge. All protocol design assumed address constancy from, say, 1969 until long after NAT appeared; all such protocols require hacks in the presence of NAT, and these hacks have operational costs as well as failure modes.

The intention of RFC2101 was to bring this issue to the IETF's attention, but it seems to have largely failed so far.

As noted by Måns, at least some operators are now very concerned about the OPEX impact of CGNAT. That's a good sign.

   Brian

In 1985, the end points typically weighed 800lb and were not likely to move. A user was not going to switch networks during a call.

Today, being able to keep the transport connection going when the network connection changes is table stakes for new proposals. And that means the IP addresses are going to be in a state of flux. If you don't want pervasive surveillance knowing who is talking to whom, you want to obliterate any information that might help an attacker.

Architecture is a dynamic concept, not something that is static. At one point, the network in my house was running off the MAC addresses for local routing. But what happens when I switch on the SDN? Now we have an IP network running on top of an IP network.


On Wed, Jul 3, 2024 at 2:15 AM Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx <mailto:moore@xxxxxxxxxxxxxxxxxxxx>> wrote:

    __

    On 7/2/24 17:04, John R Levine wrote:

    For operations within an enterprise, that's clearly true. For
    public access outside the DMZ, being accessible via IPv6 will, I think,
    be an increasing advantage as deployment of IPv6 at the consumer edge
    continues to increase.

Given how hostile consumer ISPs are to retail customers runing servers visible to the public, I don't get it.  It makes P2P stuff somewhat easier but UPNP and STUN already let you do a lot of it from behind a NAT.

    The requirements for NAT traversal drastically increase the cost and decrease the reliability of apps that need to do that.   UPNP is a security hole and STUN isn't a fix at all, sort of a bandage at best.

    Keith






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

  Powered by Linux