ietf
[Top] [All Lists]

Stupid NAT tricks and how to stop them.

2006-03-27 09:41:33

From: Henning Schulzrinne [mailto:hgs(_at_)cs(_dot_)columbia(_dot_)edu] 

Trying to devise ever more elaborate NAT traversal mechanisms 
that include sending keep-alives every few seconds and 
various "let's try this and then that" algorithms clearly 
don't scale if we want to get to consumer-grade reliability, 
not just interesting toys that try to stay one step ahead of 
the next stupid NAT trick.

The reason for all those 'stupid NAT tricks' is precisely the attitude you
show here

FACT: IPv4 address space is a scarce resource only viable because of NAT.

FACT: People do not want to pay their cable ISP for extra connections.

FACT: Smug exhortations to move to IPv6 ignore the fact that there is no
transition plan.

The obvious way to deploy IPv6 is to leverage the NAT infrastructure. Devise
a protocol suite that allows a NAT box to transparently support IPv4 or IPv6
on either side of the box. Evangelize to the major providers of NAT (Cisco,
Netgear, Microsoft, Belkin...). 


What I would like to come out of the IAB is a stream of documents that 1)
identify pain points that are being felt in the current Internet
architecture, 2) hold solutions workshops leading to architecture documents
that identify proposed solutions together with fair summaries of counter
proposals.

The IRTF was apparently intended to fill this role, given the pace of
Internet development an organization that works even slower than the IETF is
not capable of providing useful input on addressing a pain point.


The IETF has not had a voice in the major issues that the Internet has been
facing. On spam the IETF voice was hijacked. On Internet crime the IETF is
silent.


Thus, I think we need a separate organization (or work with a separate
organization) that does branding and certification. It's hard 
to buy a non-WiFi device in stores today; the equivalent 
consumer assurance needs to be true for core consumer and 
small-business network devices, and possibly services.

That is a good idea, but the systems design MUST meet the real needs of
actual customers. The problem with large amounts of IETF design is that
abstract engineering fetish is put ahead of meeting real users needs. 

For such a forum to be viable it would require the active participation of
the application providers. For that to happen the specs would have to result
in a sellable product which means meeting real customer requirements.


Paul Hoffman has in fact created something of the sort, it does not have the
level of consumer recognition that is required and the level of
participation is less than is needed but it could potentially be built on. 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf