On Oct 28, 2010, at 11:18, Roger Marquis wrote:
> james woodyatt wrote:
>> On Oct 28, 2010, at 09:47, Roger Marquis wrote:
>>> 
>>> What's wrong is remote apps that [...] initiate those inbound connections
>>> to [...] topologies unabstracted by NAT.
>> 
>> Let's leave aside the parts of your argument I've excised with ellipses.
>> What precisely is wrong with applications that expect to initiate flows to
>> destinations in topologies that have not been obfuscated away by a network
>> address/port translator?
> 
> Same thing that would be wrong with applications expecting access to other
> internal network details. [...]

I don't understand how this answers my question, because I don't know what's 
wrong with applications expecting to know A) what addresses the network 
presents to their peers for them, or B) what addresses the network presents to 
their peers for all their other peers.

> [...]
> End-users have good reason for not providing these details.  That's
> basically what EU Privacy Directives are all about.  By using NAT end
> users get the privacy they require, freedom from vendor lock-in, and are
> able to maintain their internal hosts and topologies as they see fit, not
> as their upstream ISP, application designers, or marketing data
> aggregators see fit.

I hope I'm inferring correctly from the above paragraph that the reason you 
find RFC 4193 insufficient is that it places the burden for using privacy 
addresses on the application hosts and leaves the enterprise network operator 
without a central control point where the privacy addressing of an entire 
network can be applied regardless of whether hosts do or do not use RFC 4193.  
Is that correct?

If so, then I-D.mrw-nat66 cannot help you; it offers no privacy addressing.  
So, right now, it sounds like there isn't a publicly defined way to solve the 
problem you're here to discuss without using a stateful IPv6/NAT, which does 
well-understood harm to the Internet architecture and the Internet community 
beyond the domain of enterprises that use it.

So, if you want IETF to consider your problem, perhaps the most expedient way 
to get that to happen is to write up an Internet Draft of your own to compete 
with I-D.mrw-nat66.  If you decide to do that, then I hope you will answer my 
question above with more clarity, because it will help to refine your proposal 
so that it mitigates as much harm to the Internet as possible, c.f. Keith 
Moore's previous comments about self-address fixing.


--
james woodyatt <[email protected]>
member of technical staff, communications engineering


_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66

Reply via email to