This is an excellent idea. I wonder if there is a way to phrase this
as a constructive agenda item? Maybe "the case against NAT in IPv6"
or something like that?
The problem here is that there are people who believe that "NAT" is
the enemy. They make a false distinction between NAT and
"architectural solutions". They love SHIM6, even if it is run in a
proxy, because it isn't NAT... But, how is SHIM6 run in a proxy all
that "architecturally" different than a NAT box with end-to-end
signaling and a significant incremental deployment problem?
Margaret
On Jan 28, 2009, at 1:42 AM, Fred Baker wrote:
Magnus:
If you grant a BOF, I would suggest that there be an agenda item to
permit those who are simply opposed to NATs to talk, and a separate
agenda item for those who would like to have discussions concerning
NATs and NAT-related technology. The reason is that we will need
some time in which "damn it I hate NATs and will DOS every
discussion of them" is specifically off-topic. I'm not opposed to
having dissent, but unless it is recognized and managed, there will
be no chance for a reasonable discussion - we will spend the whole
meeting fending off DOS.
Fred
On Jan 27, 2009, at 10:11 PM, Tony Hain wrote:
Every implementation where the network presumes omniscient
knowledge about
what the end user intended is inherently broken. GSE is not only
doing that,
it is saying that 'it doesn't matter what the end user wanted, the
network
admin for the router currently holding the packet gets to do
whatever they
want to the header'. There will be no way to diagnose what is going
on,
because every packet could take a very different path as each hop
along the
way distorts reality with its own nat66 policy, which might include
load-balancing.
It looks like the only cure for this nat66 nonsense is to mandate AH
everywhere...
Tony
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf
Of Fred Baker
Sent: Monday, January 26, 2009 8:42 PM
To: Brian E Carpenter
Cc: Christian Huitema; 'Margaret Wasserman'; [email protected]; 'Magnus
Westerlund'
Subject: Re: [nat66] Preliminary BOF Request
Then you must be talking about a very different GSE than I am.
On Jan 26, 2009, at 9:35 PM, Brian E Carpenter wrote:
It seems to me that these points were all discussed at some
length, if not in the same exact words, in RFC 4864.
I'm not seeing anything new in this discussion, except
the idea of using NAT66 instead of providing architectural
solutions to the gaps identified in that RFC.
Brian
On 2009-01-25 21:57, Rémi Després wrote:
Christian, Fred,
I had a similar but longer list in a presentation in Minneapolis
(http://www.ietf.org/proceedings/08nov/slides/behave-15.pdf slide
3):
1. Local addressing independence (Easy renumbering)
2. Multi-homed CPEs
3. Incoming connection filtering
4. Topology Hiding (invisibility of private routing plans)
5. Host privacy (no visible association of connections to
individual
hosts).
While points 1-4 are essentially in agreement with Christian's 1-4
(permuting 1 & 3, and 2 & 4, and making them somewhat more
explicit),
point 5 should IMO be added to Christian's list:
- Consecutive HTTP requests from a browser that doesn't keep
cookies
cookies cannot, from the outside of a NAT44 site, be recognized as
coming from the same host.
- Some users may wish, in IPv6, to keep this type of NAT44
dependent
privacy , at least for some of their web activities.
Another point made in Minneapolis, is roughly that, if CPEs are
NAT66
capable in any way, hosts should be able to control whether they
are
permitted to modify addresses or not (noted by Dave Thaler in the
last
sentence of http://www.ietf.org/proceedings/08nov/minutes/
behave.txt):
- In IPv6, host should be able to protect *end-to-end
transparency*
whenever and wherever desirable for applications.
- This capability, which has been lost in IPv4 with NAT44s, should
not
be lost also in IPv6.
This point should IMO be in the list of items to be discussed.
Regards,
RD
Fred Baker - le (m/j/a) 1/24/09 3:44 AM:
Fred Baker - le (m/j/a) 1/24/09 3:44 AM:
Pretty much
On Jan 23, 2009, at 5:52 PM, Christian Huitema wrote:
So, what are the expected benefits?
I have so far heard the following:
1) Simple security; 2) Network structure concealment; 3)
Provider
independence; 4) Multi-homing
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
