Peter and all, Peter Tattam wrote: > Hi all. > > Just weighing in on this topic, I have the following to say, and apologies if > it overlaps or has been said before. > > I believe I raised the topic several months ago, but nobody seemed to take much > notice, but I'm glad that the issues have now been discussed in more detail. > Mind you there has been little outcome except > draft-ietf-ipngwg-addrconf-privacy-00.txt which I think answers the technical > issue elegantly. Agreed and true that these issues were raised some months ago as I believe I was the first on to raised them on this list anyway. But it seems still that they are not yet viewed by someone as being critical. I of course disagree with this for obvious business and technical reasons, not to mention possible legal concerns that are bound to crop up if not addressed before large scale deployment as it seems that MCI/SPRINT and Vinton Cerf seems to be advocating. It would also seem from Scott Bradner's post yesterday, that he prefers a PR campaign rather than a technical solution. Not a wise move in my humble opinion, FWIW. > > > Given the current public concern over the privacy issue, I have decided that I > might improve our product by having an optional facility for the stack to > automatically change it's address using > draft-ietf-ipngwg-addrconf-privacy-00.txt. Ok, this seems like a reasonable starting point approach at least. > > > This raises a number of issues.. > > 1. How frequent should an address change be. One could make the changes on a > regular basis, and still retain reasonable utilization of the stack. I would > suggest making it user configuarable, but there may be some practical > limitations. It could potentially be as rapid as an address change per TCP > connection. Ok I agree completely and this is what I suggested some months ago essentially. But it went ignored and a few opposed this just recently. Per TCP connection should be adequate, unless you are doing multiple TCP connections per connection. ANd yes this should be user configurable and also default in autoconfiguration. > > > The issues to consider would be > > - what should be the minimum time between address changes Per TCP connection or per change of connection within a session should be adequate. > > > - what load on the network would be required. Presumably only one or > two ND exchanges, as well as the duplicate detection phase. Maybe also some > dynamic DNS. The address change could be scheduled to happen in advance if > necessary. Exactly right. > > > - how should the old addresses in the sequence be deprecated, presumably active > sockets should continue to work, but new connections should only use the new > address. Ok this seems adequate in most instances. > > > - how long should we continue to respond to a deprecated address if there are > no active sockets bound to that address. 20 to 30msec. > > > In all these areas, I presume there would be similar semantics to multihoming. > > 2. With my ISP hat on, there might be significant security issues with > allowing this type of mechanism to be common place, and it also brings into the > spotlght address auto config even without the random address assignment. It is > important for ISPs to track which user is one which address for accounting > reasons and also for security reasons. I don't agree here. Accounting can be done on the user him/herself not on the IP assigned at connect time. > > > >From the accounting side, if an ISP can't tell which user is using which > address, some traffic might be untraceable. Systems for logging traffic might > result in incorrect records, and there might also be implications for protocols > like RADIUS. RADIUS can indeed handle this given some modification (Minimal) > > > >From the security side, an ISP must have the ability to locate and filter a > user based on IP address since a potentially hostile user may be mounting a > network attack, and often the only way of locating the user is by IP address. > Having a random component in the address could be problematic. > > Having raised both of these ISP issues, I could debunk them by the comment that > in practice, a user might be identifiable by the top 64 bits of the address > anyway. While this looks likely to be the case for PPP, I am not so sure for > other technologies like cable or xDSL. If it was indeed the case, the top 64 > bits of an IPv6 address would then degenerate into the situation we currently > have in IPv4 with privacy of addresses. > > The issue of auto addr conf for IPv6 may also cause difficulties for > technologies that rely on strong binding between mac addresses and IP > addresses. e.g. Cable & xDSL. > > How does the ISP deal with this? Do they filter and account for IPv6 traffic > *only* matching the mac address of the customers equipment, or do they allow > willy nilly Ipv6 addresses using auto conf and track and account using the MAC > address on the wire which is only available at the connect point. > > This hasn't been an issue in v4 because addresses are so scarce that the ISP > can dictate to the customer which Ipv4 address they must use. Not so in IPv6. > Typically tools for logging are based on IP addresses which is usefule because > the logs can be applied at all parts of the network. Having to do it by mac > address means that the logging would need to be done closer to the client which > might be impractical under some circumstances. > > There is a counter argument that would imply that customers would need to be > protected from each other anyway. Does this then imply that each customer > receives their own /64 presumably staticly configured at the ISP end possibily > defeating the whole purpose of address autoconfig. > > Regards > > Peter > -- > Peter R. Tattam [EMAIL PROTECTED] > Managing Director, Trumpet Software International Pty Ltd > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail [EMAIL PROTECTED] Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208
