Thanks for your comments Brian.
a) Please note that this document is intendened to be informational. It
isn't meant to describe fixes to anything, but rather to define the
problem cases. Not all of them are related to NAT (e.g. application
proxies and overlay networks). There is perhaps some more detail
required in the draft to describe the receiver-side operations that are
problematic as a result of address sharing.
b) You're absolutely right. That's an important oversight. There is some
decent guidance in RFC6967 (published in intarea) that should probably
at least be referenced here and in any solution draft.
c) See my comment on a above. Application proxies and overlay networks
are both use cases that apply to both IPv4 and IPv6, perhaps some of the
others do too. The draft should probably be updated to updated to call
out the cases that persist beyond the final sunsetting of IPv4.
--Brandon
On 03/06/2014 06:03 PM, Brian E Carpenter wrote:
a) Since this is fixing some of the damage done by NAT, it's
really unfinished business for BEHAVE, which if iirc was a
Transport Area WG. Just saying...
b) The word "privacy" doesn't appear in the draft. Discussing
privacy aspects is clearly essential if there is any thought of
advancing this work. Actually I doubt if such a host ID is ever
going to be acceptable from a privacy point of view, unless the
end system is at liberty to change it at random (like RFC 4941).
c) A hard-nosed argument is that since we want to sunset IPv4,
it's time to stop working on ways of making NAT solutions work
better. Is there anything in the use cases that can't be fixed by
native IPv6?
(The use case in expired draft
http://tools.ietf.org/html/draft-sarikaya-fmc-prefix-sharing-usecase-01
is not at all convincing to me, especially when adding the privacy
argument. It actually seems to describe a bug in 3GPP. But in any case,
the draft appears to suggest mitigations.)
Regards
Brian
On 07/03/2014 05:28, joel jaeggli wrote:
Greetings int-area and hiaps-mailing-list folks,
I realize that this is midweek at the IETF, however this question is not
far from several discussions I've had this week.
I have been asked to consider AD sponsoring
http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04
In the process of considering doing so I'd like to get some input with
respect to:
A. The appetite for pursuing some or any of this work in existing
working groups, and in particular within the INT area.
B. A consensus basis for moving beyond RFC 6269 into active work in this
area.
C. How we address concerns raised by the IETF community expressed
through draft-farrell-perpass-attack when evaluating scenarios and
beginning to address requirements and solution-space.
Obviously these are complex questions and I do not expect that we will
arrive at answers easily nor does work on this or other drafts depend on
answering them, however it's part of the dialog.
Thanks
joel
------------------------------------------------------------------------
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
--
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
