Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[Eric Klein]

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 number shortage from v4 is not the
>> same issue under v6 for example)
>> 2. Do they already exist in v6 without adding NAT
>>
>
> This was already done, and the results are in RFC 4864.
>

I know, I was one of the co-authors of that RFC. But there seems to be a
differnce of opnion as to how well we covered all pervieved needs -
otherwise this discussion would not be happening and everyone would say "oh
yeah we don't need on NAT"

But as there are people that have a percieced need for topology hiding and
port translation lets look at this compleatly and build what is needed the
first time (and prevent the need for BEHAVE to rebuild it later)

>
>
> Then we need to check:
>> 1. Is there is a solution by using NAT
>> 2. Is there is a better solution than using NAT
>>
>
> #2 was done in the gap analysis section of RFC 4864.
>
> I'm not sure what you mean by #1, because if you start with a list of the
> functions of NAT, the fact that NAT can be used for those functions just
> follows, doesn't it?


#1 asks that if NAT will not fit the real need, why use it to fit the
percieve need.


>
>
>  Only then can we make a proper and informed decission on what is needed
>> and what is unneeded legacy.
>>
>
> I think we are ready to do this, based on the information in RFC 4864.  Do
> you see anything missing from 4864 that needs to be analyzed further? If so,
> could you send specific points, and perhaps we can consider an update?
>
All of the points that have been made in this chain point to diffrent
percieved requreiments, and there are multiple proposed solutions being
tossed around.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[Keith Moore]

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 without any "external" servers.
> 
> That is a tall (not impossible, but quite tall) order, which we have
> attempted to address several times with little effect.
> 
> And let us be very clear.  Network admins have been asking for and using
> such features for at least 18 years, well before NAT.
> 
> I would recommend separating the problems.  The NAT solution, as I
> understand it, does not make this problem worses.  That is about all one
> can ask of the NAT side of the equation.

the problem with separating the problem is that we'll solve the "easy"
part first (the NAT part) and put off trying to solve the biggest part
of the problem that is really keeping applications from working
efficiently or reliably ... and meanwhile we'll have done nothing to
improve security either.

Keith
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[Joel M. Halpern]

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.


That is a tall (not impossible, but quite tall) order, which we have 
attempted to address several times with little effect.


And let us be very clear.  Network admins have been asking for and using 
such features for at least 18 years, well before NAT.


I would recommend separating the problems.  The NAT solution, as I 
understand it, does not make this problem worses.  That is about all one 
can ask of the NAT side of the equation.


Yours,
Joel M. Halpern

TJ wrote:

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 NAT, nor to determine a host's
'external' IP address or port, nor to listen for traffic intended for a host
behind a NAT.  All of this functionality (and more) needs to be "built in"
to the NAT itself."

In fact, I think this (end nodes awareness of their "real" external address
and port) should be one of the, if not the, biggest design goals for NAT66
... assuming we do "define" it.  This enables the NAT to still "do its
thing", while still retaining the ability for apparent end to end
communications.  


Additionally, something like [ ~UPnP | NAT-PMP | NAT-XC | ALD ] to allow
firewall pinhole creation might just be useful, with a note of concern
around security of course ... 




/TJ



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Keith Moore
Sent: Tuesday, November 25, 2008 5:43 PM
To: David Morris
Cc: 'IAB'; '[EMAIL PROTECTED] WG'; 'IETF Discussion'; 'IESG IESG'
Subject: Re: [BEHAVE] Lack of need for 66nat : Long term impact to
application developers

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 forward traffic as
well as maintain the bindings in both (nay, all) endpoints' NATs.

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 NAT, nor to determine a host's
'external' IP address or port, nor to listen for traffic intended for a

host

behind a NAT.  All of this functionality (and more) needs to be "built in"
to the NAT itself.

Furthermore it's not sufficient to just define a NAT with a bidirectional,
algorithmic mapping (in order to avoid some of these
problems) because what people have come to expect from NAT (and to rely
on) is that incoming connections are denied by default.

So really, to be viable, any NAT standard needs to include some amount of
firewall functionality.  And the firewall needs to be able to keep working
even if the NAT function is turned off.

Keith
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[TJ]

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 NAT, nor to determine a host's
'external' IP address or port, nor to listen for traffic intended for a host
behind a NAT.  All of this functionality (and more) needs to be "built in"
to the NAT itself."

In fact, I think this (end nodes awareness of their "real" external address
and port) should be one of the, if not the, biggest design goals for NAT66
... assuming we do "define" it.  This enables the NAT to still "do its
thing", while still retaining the ability for apparent end to end
communications.  

Additionally, something like [ ~UPnP | NAT-PMP | NAT-XC | ALD ] to allow
firewall pinhole creation might just be useful, with a note of concern
around security of course ... 



/TJ


>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>Keith Moore
>Sent: Tuesday, November 25, 2008 5:43 PM
>To: David Morris
>Cc: 'IAB'; '[EMAIL PROTECTED] WG'; 'IETF Discussion'; 'IESG IESG'
>Subject: Re: [BEHAVE] Lack of need for 66nat : Long term impact to
>application developers
>
>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 forward traffic as
>well as maintain the bindings in both (nay, all) endpoints' NATs.
>
>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 NAT, nor to determine a host's
>'external' IP address or port, nor to listen for traffic intended for a
host
>behind a NAT.  All of this functionality (and more) needs to be "built in"
>to the NAT itself.
>
>Furthermore it's not sufficient to just define a NAT with a bidirectional,
>algorithmic mapping (in order to avoid some of these
>problems) because what people have come to expect from NAT (and to rely
>on) is that incoming connections are denied by default.
>
>So really, to be viable, any NAT standard needs to include some amount of
>firewall functionality.  And the firewall needs to be able to keep working
>even if the NAT function is turned off.
>
>Keith
>___
>Ietf mailing list
>Ietf@ietf.org
>https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[Ted Hardie]

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 applications to be used in the real (IPv4+NAT) world...

Have to deal with does not mean that the current solutions actually work.
As I said in my first message in my thread, the estimates we have for
ICE-TCP working in the real world are 40% or so, and it is the best thing
that we have.  That means real applications that already benefit from
1) having a known rendezvous/signalling path and 2) have defined
methods for using relays *still fail the majority of the time they use
TCP*.

We deal with that by not having the apps deploy.  One of the few
ways to actual get a pull for v6, rather than than exhaustion-based push,
is to have the topology sufficiently simpler that some things work there
better than they work in v4.  Introduce NAT, and you have shot that
possibility in the head, not the foot.

There is a reason we see so many systems deploying in overlay networks
at this point--the IP topology is so broken for v4 that it is better to use
a key-based routing system on top of it than to use the topology itself.
If we are giving up on this for v6 at this point, we need much more
work on dealing with overlays, because our ability to have non
client-server systems will depend largely on them.





> > A reasonable standards development effort would not blindly endorse
> > something known to be detrimental,

>Standards development effort != endorsement.

But the IETF sells itself as something that gets cross-area review and gives
a benefit in understanding how a technology fits in the ecosystem.  If we
aren't going to pay attention to it when it comes, we have relatively
little value beyond a cheaper industry consortium.  The review on
this is trying to express real concerns.You have people offering to
do real work to come up with solutions that meet the need without
this breakage.  That's not possible, obviously, if the need is "introduce
NAT", but if the need is expressible in security properties or a threat
model, I personally believe we can do much, much better.

Happy Thanksgiving,
Ted


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[james woodyatt]

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 tempted to copy and paste highlights from that ancient  
scripture here, but I don't think I'd know where to stop.  As the  
kiddies say, Read The Whole Thing.


The basic problem with NAT66 is that it introduces the possibility of  
more than one global IPv6 address realm.  Where there is more than  
one, there is *any* number, not just the current realm and the single  
realm on the other side of the relevant NAT66 box.  Fixing your self- 
address in whatever address realm any given communications peer  
happens to reside is the canonical problem that NAT causes for  
applications developers, and NAT66 is no exception to that.


If we're going to go very far down this road toward standardizing on a  
NAT66 "solution," then I would humbly suggest that it doesn't make  
much sense for there to be a single global DNS horizon where we have  
multiple global address realms.  Do the proponents of NAT66 have any  
proposals for extending DNS appropriately to support the architecture  
that NAT66 implies?


Do we really want to open the can of worms that multiple global DNS  
horizons represents?  I should hope not.



--
james woodyatt <[EMAIL PROTECTED]>
member of technical staff, communications engineering


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[Magnus Westerlund]

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 of a server that lives in global
>> address space -- or for that matter, on a bank of servers that exist to
>> do nothing but forward traffic?  isn't that what the network is supposed
>> to do?
> 
> That is what bothers me too. sip is mostly peer to peer, so for most
> of your communication (in megabytes) no server in a rack needed.
> 
> Email, with fixed IPv6 addresses will become peer to peer again too.
> 
> html? html is not much traffic. Many people do html hehind their NAT44
> boxes today.
> 
> There is still a lot to be done for zeroconf, so DNS still is ok
> with a server in a rack.
> 
> Oh, I forgot. For DNS you are still dependent on IPv4.
> 
> All the enthusiasts with their linux and freebsd boxes using ISATAP
> to communicate don't see a need for NAT66. It is the big guys with
> big windows servers who really need NAT66 to hide their fragile
> machines from the bad wild internet.
> 
> I am one of those poor guys who has never been told what good NAT66
> can do for him. I am still troubled by NAT44 preventing me from
> connecting with my ISATAP interface.
> 
> I am running more than one computer. That is why I am imprisoned
> behind my NAT44 and I am afraid NAT66 will be yet another prison.
> 
> I have seen with tunneling (slow as molasses) I get only a single /128.
> So I guess a bilingual router will sit on both his single IPv4 and
> another single IPv6 and keep all the traffic for himself letting
> me do the guesswork how to drill the holes I need to connect to
> the internet.
> 
> I see with IPv6 I do have to compete with my fridge and the
> central heating drilling holes to talk to the butcher, the baker
> and the oil-tanker. None of them is living in a rack in a colocation.
> They all have to drill holes into their NAT66 to talk to my home.
> 
> There is a hole industry living from selling me super excluse
> and expensive drilling machinery, I would not need if there was
> not a NAT66 in the first place.
> 
> I know NAT44 is like my front door and keeps the bad internet out.
> But it is not NAT44, it is the firewall who keeps them out.
> 
> Only a vague feeling for symmetry keeps telling me I should have
> a NAT66.
> 
> Math is telling me that need not be true. IPv4 brought us from
> point to point clothes line to 2-dimensional space spanning
> continents. IPv6 will bring us 3-dimensional space spanning
> the globe and DNT will bring us even further. I do not know if
> there is such a thing as NAT66 existing.
> 
> In  2-D space we do have trigons, squares, pentagons, hexagon...
> In  3-D space live stops with things built from pentagons.
> 
> The guys with their big windows servers behind NAT44 are living
> in a 2-D world, dreaming their 2-D dreams bout selling us
> 3-D NAT66 boxes without even knowing the math.
> 
> Kind regards
> Peter
> 


-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
--
Multimedia Technologies, Ericsson Research EAB/TVM
--
Ericsson AB| Phone  +46 10 7148287
Färögatan 6| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [EMAIL PROTECTED]
--
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[Noel Chiappa]

> 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 don't
remember X.25, "ATM with a larger cell size").

Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[Iljitsch van Beijnum]

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 seem too onerous. Or do you disagree?


Who do you ask??? Your note assumes there is only one 'outside', so  
any
server could answer the question. There is absolutely no restriction  
on
where and how topology warts are deployed, so asking a server in  
network A
what your address will appear to be to network B is fundamentally  
absurd.


Well, the case where my externally visible address is different  
depending on who I talk to makes it fundamentally impossible to set up  
peer to peer connections if the other end is living with the same  
limitation, so we'd have to define this such that only a single  
translation is permitted at a time.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[Keith Moore]

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 the real (IPv4+NAT) world...

Yeah, but we're trying to get rid of that stuff, or at least
considerably reduce the cost and complexity, because (among other
things) it presents a huge barrier to adoption of new multiparty apps.

>> A reasonable standards development effort would not blindly endorse
>> something known to be detrimental,
> 
> Standards development effort != endorsement.

According to RFC 2026, IETF standardization is a kind of an endorsement,
because it's a statement of both protocol quality and community consensus.

> The architecture is _ALREADY_ broken.  66NAT is merely another symptom
> of the underlying disease.

Just because a disease exists does not mean we have to encourage its spread.

The only reason for IETF to standardize some kind of 66NAT is to
significantly improve the situation over what would happen in the
absence of standardization.  There are several ways that we could
probably do that.   But one of them is NOT to standardize NATs like they
exist in IPv4.  We already know that that sucks really badly, and it
would never meet the criteria defined in RFC 2026.  Nor would it achieve
community consensus.

Keith
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[David Conrad]

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) world...



A reasonable standards development effort would not blindly endorse
something known to be detrimental,


Standards development effort != endorsement.

I considered NetBIOS to be wildly offensive and actively detrimental,  
but RFC 1001 and 1002 were appropriate codifications of NetBIOS over  
TCP/UDP/IP.



Instead all we get is complaints that anyone not


helping detail how to ship the broken architecture is ignoring  
reality and

off in a fantasy land, when the exact opposite is closer to the truth.


The architecture is _ALREADY_ broken.  66NAT is merely another symptom  
of the underlying disease.


Regards,
-drc

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[Keith Moore]

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) "There is no valid reason for 66nat" and
B) "There are obvious ways to solve the problems that people want to
solve with 66nat that are both easier to understand and technically
superior"

The two statements should have equivalent truth values, but the second
one is more illuminating.

It follows that if we want people to avoid using 66nat, we need to (a)
identify or provide technically superior solutions that are easy to
understand and (b) make them obvious to people.

Keith
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[Keith Moore]

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 covering that problem. 
> I'm tempted to copy and paste highlights from that ancient scripture
> here, but I don't think I'd know where to stop.  As the kiddies say,
> Read The Whole Thing.
> 
> The basic problem with NAT66 is that it introduces the possibility of
> more than one global IPv6 address realm.  Where there is more than one,
> there is *any* number, not just the current realm and the single realm
> on the other side of the relevant NAT66 box.  

I'm not sure about that.  Conflicting use of address space is probably
the biggest single source of NAT-related pain that network operators
experience.  If enterprise network operators can still NAT without
reusing the same addresses in different realms, I think they'll mostly
do so.  And regardless of what else happens with NAT66, I think it's
reasonable for IETF to make it really clear that apps aren't expected to
deal with conflicting address assignment in IPv6.

> Fixing your self-address in whatever address realm any given
> communications peer happens to reside is the canonical problem that NAT
> causes for applications developers, and NAT66 is no exception to that.

No, it's only one of several canonical problems that NAT causes for
applications developers.  If we narrow the focus to that one problem,
we'll miss the boat - we won't produce a "solution" that makes life any
easier for apps developers.

> If we're going to go very far down this road toward standardizing on a
> NAT66 "solution," then I would humbly suggest that it doesn't make much
> sense for there to be a single global DNS horizon where we have multiple
> global address realms.

If we were going down that road, I'd agree with you.

But I'll make a stronger statement - any "solution" to NATxx (for any
value of xx) that requires split DNS should be considered a non-starter.
 It doesn't make much sense to improve consistency at the IP naming
layer if you're going to degrade consistency at the DNS naming layer.

Keith

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[Tony Hain]

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 realizing they didn't need it. 

> 
> > The only justifications being given are
> > 'people will do it anyway', and 'we have to move quickly because
> > vendors are
> > trying to build it'. This is called railroading in any other
> > context, and
> > absolutely no long term thought is going into the impact and
> > inability to
> > remove this once it is unleashed.
> 
> So, if vendors are trying to build it, it would seem to me that an
> industry group focused on standardizing its functionality would be a
> good thing, otherwise we get into the same mess we got into with IPv4.
> 
> If vendors aren't trying to build it, no significant harm is done
> (other than the waste of time for folks participating in the
> standardization).
> 
> Putting our fingers in our ears and singing "la la la" because we
> don't think a particular technology should exist is unlikely to be
> particularly beneficial.

This is not about ignoring the technology, it is about blindly legitimizing
short-term money making for a few box vendors at the long term expense to
the entire Internet application development and end user community. If it
were simply a stand-alone technology, it would have to show value before
being deployed. It is not, because the IPv4 version of it became mandatory,
and due to marketing crap synonymous with firewall. This ensures people will
deploy it a) without awareness as a default 'security' config, or b) because
they have completely drowned in the nat==security kool-aid. Either way the
app developers will have to rely on topology awareness crutches to deal with
the resulting nonsense. 

A reasonable standards development effort would not blindly endorse
something known to be detrimental, simply because one constituency plans to
make a quick buck. We do have an Architecture Board, and a Steering Group,
so one would think we have reason to be thoughtful about the long term
impacts of what we publish. Instead all we get is complaints that anyone not
helping detail how to ship the broken architecture is ignoring reality and
off in a fantasy land, when the exact opposite is closer to the truth.
Rushing to restock the drug dealers while claiming we have no hand in the
outcome is about as far from reality as one can get.

Tony


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[Keith Moore]

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 both (nay, all) endpoints' NATs.
> 
> Keith> If we're going to standardize NATs of any kind, they need
> Keith> to be defined in such a way that no "external" server is
> Keith> necessary - not to determine one's external IP address, nor
> Keith> to forward traffic between hosts that are all behind NATs,
> Keith> nor to maintain state in the NAT, nor to determine a host's
> Keith> 'external' IP address or port, nor to listen for traffic
> Keith> intended for a host behind a NAT.  All of this
> Keith> functionality (and more) needs to be "built in" to the NAT
> Keith> itself.
> 
> 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?
> 
> How about the existing proposal plus an IPV6 anycast address for a
> stun-like protocol?  If not, why not?

I don't think so in either case.  The reason I don't think so is that I
suspect the NAT traversal problem is really a firewall traversal problem
in disguise.

People say they want NATs when what they mostly want is stateful
firewalls and maybe some topology hiding.  We might get them to move to
stateless NATs with bidirectional algorithmic mapping and a STUN-like
protocol, but they'll still want a statefull firewall to be bundled in
to block incoming connections.  And if there's a statefull firewall that
denies incoming connections by default, there will still be a need for
an intermediary in the network "core" that can arrange for traffic to be
forwarded between two hosts that are behind firewalls.  And there will
be little incentive for any network admin to get rid of NAT, because as
long as those firewalls are in the way, doing so won't enable many more
applications.

So if we really want to get rid of NAT, I think we have to resolve a
tussle between users and application developers on one hand, and
enterprise network operators on the other.  The tussle is over two
things: (1) how to restrict the kinds of traffic that can be sent over
the network, how to communicate those restrictions to apps, and what
kind of behavior is reasonable for apps that are presented with such
restrictions.  (2) to what extent network admins can control what
programs are used on hosts that attach to their networks.

Hey, I didn't say it was easy.  But I don't think anything less will get
rid of the need for the kinds of workarounds apps currently have to use
to deal with NATs.  Even if we got rid of NAT, we wouldn't solve the
problem (and NATs wouldn't matter too much) if apps still have to use
those workarounds.

Keith
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[David Conrad]

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  
vendors are
trying to build it'. This is called railroading in any other  
context, and
absolutely no long term thought is going into the impact and  
inability to

remove this once it is unleashed.


So, if vendors are trying to build it, it would seem to me that an  
industry group focused on standardizing its functionality would be a  
good thing, otherwise we get into the same mess we got into with IPv4.


If vendors aren't trying to build it, no significant harm is done  
(other than the waste of time for folks participating in the  
standardization).


Putting our fingers in our ears and singing "la la la" because we  
don't think a particular technology should exist is unlikely to be  
particularly beneficial.


Regards,
-drc

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[Tony Hain]

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 ask??? Your note assumes there is only one 'outside', so any
server could answer the question. There is absolutely no restriction on
where and how topology warts are deployed, so asking a server in network A
what your address will appear to be to network B is fundamentally absurd. I
have heard similar comments from the document authors recognizing this
problem, but hand-waving something about asking a service before populating
DNS, while completely ignoring the fact that there is no way to predict in
advance who will want to know or where they will be attached. Essentially a
server is not reachable until it guesses that network B exists, someone
wants to contact it from there, and where the service is to ask about the
address that the server appears to be. 

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'. This is called railroading in any other context, and
absolutely no long term thought is going into the impact and inability to
remove this once it is unleashed. 

Tony

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[Sam Hartman]

> "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) endpoints' NATs.

Keith> If we're going to standardize NATs of any kind, they need
Keith> to be defined in such a way that no "external" server is
Keith> necessary - not to determine one's external IP address, nor
Keith> to forward traffic between hosts that are all behind NATs,
Keith> nor to maintain state in the NAT, nor to determine a host's
Keith> 'external' IP address or port, nor to listen for traffic
Keith> intended for a host behind a NAT.  All of this
Keith> functionality (and more) needs to be "built in" to the NAT
Keith> itself.

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?

How about the existing proposal plus an IPV6 anycast address for a
stun-like protocol?  If not, why not?




I'm a bit concerned about adding requirements that would involve
solving the NAT discovery problem.  We've already had a lot of bad
luck with that approach in protocols like midcom, nsis, etc.

In contrast, in environments where it works, stun has been quite successful.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[Keith Moore]

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 forward
traffic as well as maintain the bindings in both (nay, all) endpoints' NATs.

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 NAT, nor to determine a
host's 'external' IP address or port, nor to listen for traffic intended
for a host behind a NAT.  All of this functionality (and more) needs to
be "built in" to the NAT itself.

Furthermore it's not sufficient to just define a NAT with a
bidirectional, algorithmic mapping (in order to avoid some of these
problems) because what people have come to expect from NAT (and to rely
on) is that incoming connections are denied by default.

So really, to be viable, any NAT standard needs to include some amount
of firewall functionality.  And the firewall needs to be able to keep
working even if the NAT function is turned off.

Keith
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[Peter Dambier]

Keith Moore wrote:

> absolutely it's too onerous.  why in the world should an application's
> deployability depend on the existence of a server that lives in global
> address space -- or for that matter, on a bank of servers that exist to
> do nothing but forward traffic?  isn't that what the network is supposed
> to do?

That is what bothers me too. sip is mostly peer to peer, so for most
of your communication (in megabytes) no server in a rack needed.

Email, with fixed IPv6 addresses will become peer to peer again too.

html? html is not much traffic. Many people do html hehind their NAT44
boxes today.

There is still a lot to be done for zeroconf, so DNS still is ok
with a server in a rack.

Oh, I forgot. For DNS you are still dependent on IPv4.

All the enthusiasts with their linux and freebsd boxes using ISATAP
to communicate don't see a need for NAT66. It is the big guys with
big windows servers who really need NAT66 to hide their fragile
machines from the bad wild internet.

I am one of those poor guys who has never been told what good NAT66
can do for him. I am still troubled by NAT44 preventing me from
connecting with my ISATAP interface.

I am running more than one computer. That is why I am imprisoned
behind my NAT44 and I am afraid NAT66 will be yet another prison.

I have seen with tunneling (slow as molasses) I get only a single /128.
So I guess a bilingual router will sit on both his single IPv4 and
another single IPv6 and keep all the traffic for himself letting
me do the guesswork how to drill the holes I need to connect to
the internet.

I see with IPv6 I do have to compete with my fridge and the
central heating drilling holes to talk to the butcher, the baker
and the oil-tanker. None of them is living in a rack in a colocation.
They all have to drill holes into their NAT66 to talk to my home.

There is a hole industry living from selling me super excluse
and expensive drilling machinery, I would not need if there was
not a NAT66 in the first place.

I know NAT44 is like my front door and keeps the bad internet out.
But it is not NAT44, it is the firewall who keeps them out.

Only a vague feeling for symmetry keeps telling me I should have
a NAT66.

Math is telling me that need not be true. IPv4 brought us from
point to point clothes line to 2-dimensional space spanning
continents. IPv6 will bring us 3-dimensional space spanning
the globe and DNT will bring us even further. I do not know if
there is such a thing as NAT66 existing.

In  2-D space we do have trigons, squares, pentagons, hexagon...
In  3-D space live stops with things built from pentagons.

The guys with their big windows servers behind NAT44 are living
in a 2-D world, dreaming their 2-D dreams bout selling us
3-D NAT66 boxes without even knowing the math.

Kind regards
Peter

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[David Morris]

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 not being heard.
> >
> > Not sure that's entirely true...
> >
> > 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?
>
> absolutely it's too onerous.  why in the world should an application's
> deployability depend on the existence of a server that lives in global
> address space -- or for that matter, on a bank of servers that exist to
> do nothing but forward traffic?  isn't that what the network is supposed
> to do?

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. A
ip-ip mapping lookup service, probably not all that different than DNS or
the service the telcos use to map 8xx numbers to actual phones, or phone
numbers to specific terminal devices on specific carriers.

I don't know if that is a good approach or not but I find it quite a bit
less onerous than routing all traffic via an intermediate server. And it
seemed the question wasn't understood.

Dave Morris
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[Keith Moore]

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 true...
> 
> 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?

absolutely it's too onerous.  why in the world should an application's
deployability depend on the existence of a server that lives in global
address space -- or for that matter, on a bank of servers that exist to
do nothing but forward traffic?  isn't that what the network is supposed
to do?

Keith
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[Iljitsch van Beijnum]

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 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?

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[Peter Dambier]

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 NAT that is not
an obstacle but a stepping stone.

Kind regards
Peter


Eric Klein wrote:
> 
> 
> 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.
> 
> 
> Yes, there is a very clear anti-NAT religion that drives a lot of
> thought. It's not clear that any other opinion is tolerated.
>  
> 
> Fred,
>  
> I pesonally would be open to a real discussion about the needs and then
> about the solution. But for now NAT has taken on religious connotations
> with those who are for it being as single minded as those who are
> against it.
>  
> 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 number shortage from v4 is not the
> same issue under v6 for example)
> 2. Do they already exist in v6 without adding NAT
>  
> Then we need to check:
> 1. Is there is a solution by using NAT
> 2. Is there is a better solution than using NAT
>  
> Only then can we make a proper and informed decission on what is needed
> and what is unneeded legacy.
> Eric
> 
> 
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[Eric Klein]

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.
>>
>
> Yes, there is a very clear anti-NAT religion that drives a lot of thought.
> It's not clear that any other opinion is tolerated.
>
Fred,

I pesonally would be open to a real discussion about the needs and then
about the solution. But for now NAT has taken on religious connotations with
those who are for it being as single minded as those who are against it.

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 number shortage from v4 is not the same
issue under v6 for example)
2. Do they already exist in v6 without adding NAT

Then we need to check:
1. Is there is a solution by using NAT
2. Is there is a better solution than using NAT

Only then can we make a proper and informed decission on what is needed and
what is unneeded legacy.
Eric
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[Margaret Wasserman]

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 number shortage from v4 is not  
the same issue under v6 for example)

2. Do they already exist in v6 without adding NAT


This was already done, and the results are in RFC 4864.


Then we need to check:
1. Is there is a solution by using NAT
2. Is there is a better solution than using NAT


#2 was done in the gap analysis section of RFC 4864.

I'm not sure what you mean by #1, because if you start with a list of  
the functions of NAT, the fact that NAT can be used for those  
functions just follows, doesn't it?


 Only then can we make a proper and informed decission on what is  
needed and what is unneeded legacy.


I think we are ready to do this, based on the information in RFC  
4864.  Do you see anything missing from 4864 that needs to be analyzed  
further? If so, could you send specific points, and perhaps we can  
consider an update?


Margaret

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[Tony Hain]

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
multiplied many times over due to the breadth of the application development
space. In terms of the overall costs to the system, squeezing a cost out of
the core forces a much larger cost spread all around the edges. 

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. 

Tony

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Fred Baker
> Sent: Friday, November 21, 2008 10:08 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED] WG; IAB; IETF Discussion; IESG IESG
> Subject: Re: [BEHAVE] Lack of need for 66nat : Long term impact to
> application developers
> 
> 
> 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.
> 
> Yes, there is a very clear anti-NAT religion that drives a lot of
> thought. It's not clear that any other opinion is tolerated.
> ___
> Behave mailing list
> [EMAIL PROTECTED]
> https://www.ietf.org/mailman/listinfo/behave

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf