Re-, If /128 is used to enforce the policies then there is no issue at all. The point is that using /128 to black list a spammer for instance is not efficient; that's why it is likely servers will use the first 64 bits (or even /56) to install a filter....the damage can be restricted to a home premises or a large number of customers when NPTv6 is used or any other deployment context requiring the share the first 64 bits.
Does this makes sense to you? Cheers, Med >-----Message d'origine----- >De : Joel M. Halpern [mailto:j...@joelhalpern.com] >Envoyé : mardi 21 août 2012 15:49 >À : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : Internet Area >Objet : Re: [Int-area] Nat Reveal Analysis > >Thank you for your prompt attention. >I have removed the agreed items. >I am still confused by the proposed new IPv6 text. >The text says that if a server uses short prefixes it will apply the >policy too coarsely. >On the one hand, that is true even if NPT66 is not used. >On the other, the solution is already present. Use the full 128 bits. >This does not require any new mechanisms. > >Yours, >Joel > >On 8/21/2012 1:35 AM, mohamed.boucad...@orange.com wrote: >> Dear Joel, >> >> Thank you for the review. >> >> Please see inline. >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : int-area-boun...@ietf.org >>> [mailto:int-area-boun...@ietf.org] De la part de Joel M. Halpern >>> Envoyé : lundi 20 août 2012 22:52 >>> À : Internet Area >>> Objet : [Int-area] Nat Reveal Analysis >>> >>> My thanks to the authors for submitting a revised version of >>> draft-ietf-intarea-nat-reveal-analysis-03. >>> >>> I have looked at this document, and have a few comments. >>> First, thank you for removing the explicit recommendation. >>> >>> I find section 2.1 on IPv6 applicability somewhat >confusing. The most >>> common technique I know of for topology hiding, NPT66, does so in a >>> fashion that does not conflate identities. As such, it is >not obvious >>> that there is an IPv6 problem. It seems that this short >>> section should >>> either be removed or elaborated. >> >> Med: I updated the text as follows: >> >> OLD: >> >> Some of the issues mentioned in Section 2 are >independent of IPv4 vs. >> IPv6. Even in IPv6, address sharing can be used for a variety of >> reasons (e.g., to hide network topology, to defeat hosts from >> offering network services directly, etc.). >> >> NEW: >> >> Some of the issues mentioned in Section 2 are >independent of IPv4 vs. >> IPv6. Even in IPv6, address sharing can be used for a variety of >> reasons (e.g., to hide network topology, to defeat hosts from >> offering network services directly, etc.). >> >> An example is an NPTv6 translator [RFC6296] using a prefix longer >> than /56 for its algorithmic address mapping. In such >context, if a >> remote server enforces policies (e.g., blacklist a >misbehaving user) >> based on the first 48 or 56 bits, several IPv6 hosts will be >> impacted. >> >> Is the new text better? > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
