On 13 nov 2008, at 22:15, Hallam-Baker, Phillip wrote:
Well yes, that is precisely the reason I beleive that we need to
take a look at a higher level and decide on one single answer
A single answer? That doesn't seem compatible with what the internet
has evolved into over the past decades.
to questions such as:
* What describes the boundary between the network and the inter-
network?
* How does a client endpoint connect to a service endpoint?
* How does a sevice endpoint advertise its existence at the network
border?
Sounds an awful lot like the telco networks of yore. One of the cool
things about the internet architecture is that many aspects of it are
recursive. Having these borders is incompatible with that. On the
other hand, many service providers use nasty hacks to get their stuff
to work (just think about a concept like putting authentication in
DHCP!) because the IP architecture doesn't allow for a service
provider / customer demarcation point.
By infrastructure here I am taking account of the fact that we might
in theory replace the DNS protocol, but only if the result was
transparent at a logical level.
And how would the new DNS be better than the old one, apart from such
obvious things as removing the easy spoofing?
The reason that people
Many of the problems with NAT result from the fact that we have
protocols such as FTP that use the IP address and port to pass a
pointer to a service endpoint - yuk!
is that you can't realistically do a referral based on a DNS name:
- DNS isn't always available
- DNS is insecure
- caching and TTLs and incorrect implementation of same make that an
inconsistent view of the same data in different places can persist for
significant amounts of time
- performance is relatively poor
- some users don't have a DNS name
- a large number of users can't set their own DNS name
- dynamic IP addresses usually come with static DNS names, i.e., with
the address change the name changes as well
And then there is of course the issue of revisiting a very large
number of protocols and implementations of these protocols in order to
support FQDN based referrals.
But apart from these issues I agree with you.
It would be really nice if there was actually a practical,
interoperable video conferencing system that works peer-to-peer
through NAT at both ends.
Not sure how this applies to the NAT66 discussion. The choice that
we're talking about is between a type of NAT that can fairly easily
support this versus no NAT, so it also works.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf