Comments in-line... On 24 May 2013, at 16:17, Hosnieh Rafiee <[email protected]> wrote: > > I just wonder why, when you can use a monitoring system to log all your > events (MAC + IP) when you are inside a corporate network, you see this as a > big issue. You can also rotate your logs so that a large amount of storage > is not necessary. Why would you sacrifice your user's privacy over a > logging issue? If you really have no concern about user privacy, then that > become another decision and you can use public IP addresses, that are not > generated based on MAC addresses, and use them for an unlimited time which > is explained in the draft. You can use either this draft or any other > approach.
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. My current feeling is that we have Fernando's stable privacy draft that's getting quite close to being done (I hope :) and we of course have 4941. I would personally prefer to see Fernando's text published, and then - if you feel it necessary - you could issue a proposal for any additional functionality you believe is needed beyond that, or for perceived fixes to 4941. You may have valid points to make, e.g. regarding requirements on dynamic DNS when using that, but it would be easier to assess them after the publication of Fernando's work. 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. >> "In cases where the router prefix changes, the node MUST cut the > connection." >> Hmmm unhappy eyeballs and potential negative impact on graceful >> renumbering of RFC2894. > > I will change this sentence to the following: "still can keep the old > connections but MUST use a new IID with the new RAs" . This addresses the > renumbering issue. I will improve this part as I did not consider > renumbering. Check RFC4192 about non-flag day renumbering. In homenet though, we might see such "flash" renumbering. These are important considerations. >> 4) rotating the IID of link local address and other addresses could have > other >> unforeseen operational consequences on e.g. static routes, dynamic routes > that >> point to the end node, ACLs, DSCP QoS, Bandwidth Policing, VPN tunnel >> endpoints, Intrusion Detection Systems, load balancers, outbound firewall >> access authorisation .... everything where the IPv6 address is assumed to > be >> largely time invariant and is used as a key to some other relationship. > I'd like >> some more detail of that. > > In the draft there is an explanation about link local addresses that is > different than privacy addresses. This is because it is not really important > to change the local link addresses when others can see your MAC address. > When you expose your Identity via MAC, then privacy does not make sense. This is a nice property of Fernando's draft. A "random" IID per prefix, with non-disclosure of MAC. > Here I will give a brief explanation about the other issues. If you are > using VPN, then you can keep your connection for as long as you are using > it. I am not sure, but I think you use bandwidth policy not based on the IP > but based on the usernames or flow based control. If the application needs > a fixed public address, then the question becomes why would you use this > draft or any other documents that pertain to privacy? > If we are talking about privacy, then we need to also make changes to the > firewalls, like the way DDNS does. This all pertains to application > considerations for privacy. When we want to take steps toward privacy, we > need to improve many of the current systems. This will not happen in one or > two days as this or many other drafts will not be implemented in one or two > days. Well, there are many knock-on effects of peers changing IP addresses over time. Many of these have been discussed in the context of renumbering. > @ Tim: Sorry for bad English in the last messages. When I use a touch screen > device with a small screen to send messages it is really hard to recheck the > sentences. Actually, Ray wrote the comments above, but I'm impressed how much you wrote on a small screen :) Tim > > Thanks, > Regards, > Hosnieh > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
