On Mon, Nov 24, 2008 at 15:46, Margaret Wasserman [EMAIL PROTECTED]wrote:
On Nov 24, 2008, at 5:56 AM, Eric Klein wrote:
We need a team made up of both sides to sit down, spell out what are the
functions of NAT (using v4 as a basis) and then to see if:
1. If they are still relevant (like
On 25 nov 2008, at 23:10, Tony Hain wrote:
Iljitsch van Beijnum wrote:
...
But in any event, compared to the backflips through flaming hoops we
have to do in IPv4, the asking a remote server what our source
address
looks like from the outside to make address based referrals work
doesn't
From: David Conrad [EMAIL PROTECTED]
The architecture is _ALREADY_ broken. 66NAT is merely another symptom
of the underlying disease.
Hey, that's what happens when you pick as 'the next generation of networking',
X.25 with a larger sequence number space (or, for you youngsters who
Please,
any input into this debate shall go to the behave list. People
interested in this topic please subscribe to Behave.
Regards
Magnus
Peter Dambier skrev:
Keith Moore wrote:
absolutely it's too onerous. why in the world should an application's
deployability depend on the existence
On Nov 25, 2008, at 15:11, Sam Hartman wrote:
Keith, would the NAT-66 proposal plus some mechanism for a server
inside the NAT to ask the NAT for its global address be sufficient to
meet the needs described above?
No. RFC 3424 is the IAB Considerations document covering that
problem. I'm
At 6:07 PM -0800 11/25/08, David Conrad wrote:
Tony,
On Nov 25, 2008, at 4:41 PM, Tony Hain wrote:
Either way the
app developers will have to rely on topology awareness crutches to
deal with
the resulting nonsense.
Stuff they presumably already have to deal with because they'd like
their
FWIW - I wholeheartedly agree with
If we're going to standardize NATs of any kind, they need to be defined in
such a way that no external server is necessary - not to determine one's
external IP address, nor to forward traffic between hosts that are all
behind NATs, nor to maintain state in the
As far as I can tell, most of what is being asked for here has little,
if anything, to do with NAT. To paraphrase:
If we are going to have firewalls which block incoming connections,
communication between entities behind such firewalls should still be
possible without any external servers.
Joel M. Halpern wrote:
As far as I can tell, most of what is being asked for here has little,
if anything, to do with NAT. To paraphrase:
If we are going to have firewalls which block incoming connections,
communication between entities behind such firewalls should still be
possible
On 23 nov 2008, at 20:25, Tony Hain wrote:
The fundamental problem here is that the voices of those bearing the
costs
in the core are being represented, while the voices of those doing
application development are not being heard.
Not sure that's entirely true...
But in any event, compared
Iljitsch van Beijnum wrote:
On 23 nov 2008, at 20:25, Tony Hain wrote:
The fundamental problem here is that the voices of those bearing the
costs
in the core are being represented, while the voices of those doing
application development are not being heard.
Not sure that's entirely
On Tue, 25 Nov 2008, Keith Moore wrote:
Iljitsch van Beijnum wrote:
On 23 nov 2008, at 20:25, Tony Hain wrote:
The fundamental problem here is that the voices of those bearing the
costs
in the core are being represented, while the voices of those doing
application development are
David Morris wrote:
Actually, he did not say the server forwarded traffic, just that it
provided a way to learn how 'my' address was mapped through 'my' nat.
I understand. But in practice just knowing your external address is
often insufficient. You need an intermediate server that will
Keith == Keith Moore [EMAIL PROTECTED] writes:
Keith I understand. But in practice just knowing your external
Keith address is often insufficient. You need an intermediate
Keith server that will forward traffic as well as maintain the
Keith bindings in both (nay, all)
Iljitsch van Beijnum wrote:
...
But in any event, compared to the backflips through flaming hoops we
have to do in IPv4, the asking a remote server what our source address
looks like from the outside to make address based referrals work
doesn't seem too onerous. Or do you disagree?
Who do you
Tony,
On Nov 25, 2008, at 2:10 PM, Tony Hain wrote:
There is no valid reason for 66nat.
Then it will die in the marketplace and any standardization efforts
will simply fade away.
The only justifications being given are
'people will do it anyway', and 'we have to move quickly because
Sam Hartman wrote:
Keith == Keith Moore [EMAIL PROTECTED] writes:
Keith I understand. But in practice just knowing your external
Keith address is often insufficient. You need an intermediate
Keith server that will forward traffic as well as maintain the
Keith bindings in
David Conrad wrote:
Tony,
On Nov 25, 2008, at 2:10 PM, Tony Hain wrote:
There is no valid reason for 66nat.
Then it will die in the marketplace and any standardization efforts
will simply fade away.
No it won't, because people will have deployed it in default configurations
without
james woodyatt wrote:
On Nov 25, 2008, at 15:11, Sam Hartman wrote:
Keith, would the NAT-66 proposal plus some mechanism for a server
inside the NAT to ask the NAT for its global address be sufficient to
meet the needs described above?
No. RFC 3424 is the IAB Considerations document
Tony Hain wrote:
There is no valid reason for 66nat. The only justifications being given are
'people will do it anyway', and 'we have to move quickly because vendors are
trying to build it'.
Okay, let's try to be a tad more precise. There is a subtle but
important difference between:
A)
Tony,
On Nov 25, 2008, at 4:41 PM, Tony Hain wrote:
Either way the
app developers will have to rely on topology awareness crutches to
deal with
the resulting nonsense.
Stuff they presumably already have to deal with because they'd like
their applications to be used in the real (IPv4+NAT)
David Conrad wrote:
Tony,
On Nov 25, 2008, at 4:41 PM, Tony Hain wrote:
Either way the app developers will have to rely on topology
awareness crutches to deal with the resulting nonsense.
Stuff they presumably already have to deal with because they'd like
their applications to be used in
On Sat, Nov 22, 2008 at 7:07 AM, Fred Baker [EMAIL PROTECTED] wrote:
On Nov 21, 2008, at 9:39 PM, Tony Hain wrote:
The discussion today in Behave shows there is very strong peer-pressure
group-think with no serious analysis of the long term implications about
what is being discussed.
Hi Eric,
I would like to be part of that group.
My little network is connected to the internet
via a NAT router and I could not live without
it because daily renumbering wont do.
On the other hand that NAT-box is the biggest
obstacle between my network and IPv6.
I would like to help design a
This is not anti-nat religion. There are costs that every application
developer has to absorb to deal with topology warts, and the people that are
focused on their little part of the problem space refuse to acknowledge
those costs. They also refuse to recognize the fact that these costs are
25 matches
Mail list logo
