Hi Brian, Please see inline.
Cheers, Med >-----Message d'origine----- >De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Brian E >Carpenter >Envoyé : jeudi 6 mars 2014 19:03 >À : joel jaeggli >Cc : hi...@ietf.org; Internet Area; draft-boucadair-intarea-host- >identifier-scenar...@tools.ietf.org >Objet : Re: [Int-area] request to consider sponsoring >http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier- >scenarios-04 > >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... [Med] It is not only about NAT but address sharing in general (including A+P and proxies). Issues are also encountered when tunnels are in use. > >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). [Med] A pointer to http://tools.ietf.org/html/rfc6967#section-3 can be added to the draft. > >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? [Med] The document includes some cases involving IPv6 (e.g., proxies, NPTv6, NAT64). See the table in http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04#section-4.2. The text can be made more clearer. > >(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 >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > >_______________________________________________ >Int-area mailing list >Int-area@ietf.org >https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
