On 6/15/10 11:04 AM, ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com wrote:
And since I'm not in the best of moods I'll also answer in kind by
saying us application engineers might also be waiting for someone
with half a clue as to how to design a proper standard API to come
along and do that.
Ned,
Agreed, better progress should have been made. What impact do you see a
new suite of network APIs making?
It is not hard to understand a view that one should avoid making NATP
translations, where IPv6 should easily be able to avoid this issue.
When dealing with older code that should have been changed, dual stack
transitional schemes, such as ds-lite or 6to4, depend less on existing
code working directly with IPv6. Most expect port mapping agility, or
manual intervention will retain functionality by moving this function to
the realm of newer equipment. Access to maintenance interfaces is
another area where proprietary schemes are working well. Even Debian
distributions such as Ubuntu, offer pre-installed services which make
remote configuration easier and safer. Having fewer maintenance
interfaces exposed directly to the Internet is a good thing, since few
older interfaces have adequate protection.
Here is a document that explains how the aiport router supports an API
for managing port mappings:
http://tools.ietf.org/html/draft-cheshire-nat-pmp-03
This approach avoids complex service and device specific structures, and
dependence upon insecure, complex, and proprietary assignment protocols
that ultimately depend upon users being updated and knowing when to
click okay.
-Doug
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf