> At our site we do just this; an SNMP-based tool harvests IP/MAC/port data from > the switches,routers etc. I agree that it works very well. > > That said, I expect quite a few (enterprise) sites will try to disable 4941. Or if > they use ULAs as well, to disable for ULAs for internal traffic. That's their > choice. > > The question is just what additional privacy you're delivering. In principle, 4941 > addresses could be put in the DNS, or could be passed to peers to use for > communications. Conceptually, it may be simpler to have just two classes of > address; stable privacy addresses (as per Fernando's text) and "temporary" > privacy addresses which change over time (RFC 4941), whether the addresses > are used to initiate or receive connections.
This is not something different from RFC 4941 or new, but just an update to clarify the choice of words used in the RFC that deals with the handling of the lifetime. Some implementations did not make a good option choice which then allowed for a correlation to be made between their generated IIDs. It will not change the main nature of RFC 4941. Thus, if an enterprise wants to use it, then they can do so. You can also use the privacy addresses in DNS, but in this case I think it would be better to generate the privacy addresses using CGA or SSAS (new version). http://www.ietf.org/mail-archive/web/ipv6/current/msg17760.html You can then use CGA-TSIG for dynamic DNS updates and solve both the problem for privacy and DNS update. > In the meantime, it would be helpful if your draft listed the existing privacy > concerns you have, and the key benefits of your proposed mechanism(s) as > easy-to-parse bullet points in your text. You can take out some of the more > general comments about privacy, e.g. the first paragraph of the introduction. > Make the abstract more snappy, move the points in there to bullet-point > concerns in the main body, and make your proposed solution clearer. I think > that would help other readers as well. Just a suggestion at least. Thanks , I will do it in the next version. Thanks again, Regards, Hosnieh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
