--- Vernon Schryver <[EMAIL PROTECTED]> wrote:
> > From: Matt Holdrege <[EMAIL PROTECTED]>
>
> > ...
> > Just so there is no more confusion, in no way is the IETF endorsing the use
>
> > or development of NAT. You've completely missed the point of the draft.
> > It's purpose is to clearly poi
--- Jeffrey Altman <[EMAIL PROTECTED]> wrote:
> This draft is very incomplete and in my opinion not ready for prime
> time. The working group has in the past requested lists of protocols
> and applications which do not work with NATs. I have replied
> discussing those items for which I am most
Quoted from another thread:
However, we believe that there is a fairly general understanding
among IAB, ICANN, and US DoC that the IAB could, indeed, transfer
the portions of the IANA efforts that relate to IETF work elsewhere
if that were necessary or desirable.
I like this bold stat
I have so many issues with this reply that I am only going to focus on
one.
> Agreed. How do you expect the intruders will steal the tickets, without
> being recipients of the ticket? Unless, you are assuming that the private
> network is not trusted and that there are intruders within the priva
Hi,
Lack of SNMPv3 availability in networking products is a serious
operational problem in the Internet today, IMHO.
A large number of networking vendors are telling @Home that the
vendor has difficulty in offering SNMPv3 because WindRiver won't take the
Epilogue SNMP Agent softw
I'm trying to announce to the host connected to the Ethernet interface.
Yes the digital radio does have other interfaces, but I believe that only
one type of interface (ethernet or PPP) will be active at any one time,
i.e. we won't have the PPP interface working at the same time as the
Ether
I'd like to make some clarifications about Kerberos and NAT.
>> When AUTH is used with Kerberos 4 and Kerberos 5 there are issues
>> related to the IP addresses which are embedded into the Kerberos
>> tickets which specify the valid machines from which the tickets are
>> valid.
> Are you saying
The facts, as stated, are simply not true.
SNMPv3 is ported and supported for both VxWorks and pSOS+. Prior to the
merger of Wind River and Integrated Systems (which owned Epilogue),
there was no SNMPv3 solution for VxWorks. But it is available today.
SNMPv3 has been available for pSOS+ for as
This note is simply to update the record. As the whole discussion
is dealing with a single vendor followups should probably be taken
off-line.
Anyway, the port of Envoy and SNMPv3 to VxWorks is in the hands of the
manufacturing and shipping department and should be shipped to customers
shortly
John,
I called it the "Limited Broadcast Address" because that is what Richard
Stevens calls it in his book, "TCP/IP Illustrated Volume 1", which I had
thought was considered the BIBLE amongst networking professionals.
Secondly, I am aware that no router in the world forwards this address. It
> In Kerberos 4, when the KDC receives a ticket request, it includes the
> source IP address in the returned ticket. This works fine if the KDC
> is across a NAT gateway, as long as all of the Kerberos services are
> also across a NAT gateway.
doesn't this require the NAT to use the same inside<
> doesn't this require the NAT to use the same inside<->outside address
> binding for the connection between the client and the KDC as for
> the connection between the client and the application server?
> e.g. it seems like the NAT could easily change address bindings
> during the lifetime of a t
> doesn't this require the NAT to use the same inside<->outside
> address binding for the connection between the client and the KDC as
> for the connection between the client and the application server?
> e.g. it seems like the NAT could easily change address bindings
> during the lifetime of a ti
At 11:01 PM 4/20/00 +0200, Anders Feder wrote:
>The translation system being developed for the United Nations, the Universal
>Network Language (UNL), looks quite promising. Does the IETF have any plans
>regarding this system?
not specifically. Care to make an argument that we should?
> > doesn't this require the NAT to use the same inside<->outside
> > address binding for the connection between the client and the KDC as
> > for the connection between the client and the application server?
> > e.g. it seems like the NAT could easily change address bindings
> > during the lifeti
> > doesn't this require the NAT to use the same inside<->outside
> > address binding for the connection between the client and the KDC as
> > for the connection between the client and the application server?
> > e.g. it seems like the NAT could easily change address bindings
> > during the lifeti
At 05:38 PM 4/21/2000 -0400, Keith Moore wrote:
>doesn't this require the NAT to use the same inside<->outside address
>binding for the connection between the client and the KDC as for
>the connection between the client and the application server?
>e.g. it seems like the NAT could easily change a
17 matches
Mail list logo
