Hosnieh Rafiee wrote: > > follow up to the follow up: > > sorry, I sent the wrong link the last time. this is the correct link: > > http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy > > :-| it is not my day…… :-/ > > Hosnieh > I have read this draft and I don't particularly like it for several operational reasons.
1) Use of purely random unpredictable IIDs appears to impose an ISP model of working where there is no trust relationship between the end node and the network infrastructure. In corporate environments it is very important that cross-correlation of log events can occur to support various operational processes (also over longer periods of time and for examining historical records). IPv4 did not randomly rotate end node identifiers in an uncorrelated manner, and the consequences of this new behaviour could be far reaching. Even in an ISP environment, there is a requirement in many countries for a log of identifiers that have been used for communication to be available to law enforcement agencies. It could be argued that maintaining the relationship between the /64 prefix and the natural person holding the ISP contract would be sufficient, but some countries might not accept this, and impose a requirement to log all IIDs that have been used, which would be a significant burden on storage. 2) Section 3.1. Updating the IID after DAD has completed may disrupt existing communications and applications. Also if there is a collision, simply incrementing the modifier will guarantee another collision if two colliding nodes are operating draft-rafiee-6man-ra-privacy-03. 3) Section 5 & Section 6 requires dynamic DNS updates. In the event that an implementer wishes to rotate these records for privacy reasons, there may be unexpected consequences in the name space, especially in the presence of distributed DNS with e.g. caching only servers. How would they know to update their cached records? I think there's a lot more detail required here on treatment of TTL of e.g. AAAA records, plus handling of existing sessions. Applications using UDP could also be problematic: when do they time out? "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. 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. regards, RayH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
