Brian E Carpenter - le (m/j/a) 1/26/09 10:35 PM:
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.
I agree that RFC 4864 is a great starting point for all this discussion:
it contains more useful details than any reasonable e-mails
can contain, and covers well the analysis status in May 2007.
Yet, there is room left, IMHO, for BETTER isolating where, and for which
purpose, IPv6 addresses might usefully be modified in CPEs.
Only when this is done, IMHO again, it will be time to decide whether
what is left should be called NAT66, or should rather be called
differently to avoid confusion (in particular if the retained solutions
would just be "architectural").
More comments below on the two point which, in my understanding, are
worth making beyond RFC 4864:
1. HOST PRIVACY
In the gap analysis of RFC 4864, the closest reference to Host Privacy,
as I define it, is under "Minimal Traceability of Privacy Addresses" (6.3).
It suggests that privacy addresses would be a basis for a solution.
But, unless privacy addresses would be changed more frequently than
realistic, they don't prevent that, from the outside, consecutive Web
requests from a same host can be identified as such.
To do better, I introduced an approach in
www.ietf.org/proceedings/08nov/slides/behave-15.pdf, where CPEs perform
a stateless scrambling by of:
(1) the part of an internal address which is after the ISP prefix;
(2) bits 2-15 of the internal port number if it is a dynamic port.
It seems now that his scrambling should advantageously be limited to Web
requests (external port 80), to eliminate the risk of interfering with
possible expectations of other applications.
So far, no one has shown interest for this approach, but it remains on
the table.
2. HOST PRIVACY "ON DEMAND"
Let us consider a site where IPv6 internal routing is based ULAs
(typically *to avoid renumbering difficulties*, a legitimate concern),
and where at least some hosts know the /48 prefix an ISP has assigned to
their site, so that they can build their own global addresses.
Such a hosts can take as source address of its outgoing packets
either its ULA or its global address.
(Note that, in the global address case, global packets have to be
encapsulated in local ones. Otherwise, reverse path forwarding in
intra-site routing would prevent site traversal.)
- Prefix conversion by CPE(s) has to be performed if internal source
addresses are ULAs.
- Conversion must be avoided if source addresses are global (a sign of E2E
transparency expectation).
This may still be unclear, or controversial. Bu I hope it will be seen
as a contribution to the (useful) debate.
Regards,
RD
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
