Hi, Rafiee, I don't think using CGA by replacing the public key with a timestamp or other random string is a "higher randomzation" address generation method. Hash is only one technique of generating a random like string, may not be the best one among those specified in RFC4086.
ipv6-boun...@ietf.org 写于 2013-07-30 13:12:34: > Hi All, > > Many thanks to the people who commented on my draft. > Here are my responses. There was not enough time to respond to all > comments and it was difficult to discern and follow the comments one > by one from the audio tape. I had to listen to the audio repeatedly > before I could put the context of the comment together with the > subject of the slide. > > To clarify, I used public addresses because other people on the > mailing list used this term. > --------------------------------- > Response to comments related to Lifetime of the IID: > @Fernando: > Concerns: we will have thousands of IIDs if we want to generate a > new IID for each application > > Answer: > There are some variables to be considered when maintaining the > lifetime of the IID. One such variable is the maximum number of > IIDs. The maximum number of applications per IID and the maximum > lifetime of the IID. If the IID expires, it will keep its current > connections but will not be able to be used for new connections. If > a node starts an application x, then it checks whether or not any > IIDs are available whose lifetime has not yet expired. If there > is/are, then it sorts them based on their lifetime and assign > it/them to the IID with the longest lifetime. > If there is no IID available and the maximum number of IIDs has been > reached, then increase the maximum number of applications (variable > keeps this amount) for a specific IID with the longest lifetime. > If there is no IID available, but the maximum number of IIDs is NOT > reached, then generate a new IID and assign this application to it. > For more information please refer to the draft. > > @Keith Moore: > Concerns: Some applications can just use a different address for > every new application while other applications cannot, such as peer > to peer, because they would encounter a problem. > > Answer: > I assume that it is dependent on the implementation. This means, for > instance, that we can assume that we would have 1 IID for Internet > explorer and 1 IID for all sessions that were opened by one peer to > peer application. It is possible for me to clarify it in the draft > by explaining how to assign a new application to a new IID , just as > I have explained with these two examples. > > @Dave Thaler: > Concerns: Why we did not mention application layer? Is it because we > will have a large number of addresses? > > Answer: If you do not have some kind of variable to control the > lifetime, the maximum number of IIDs and the maximum number of > application per IID (as I explained a part of that algorithm to > Fernando), then your concern is valid. But if we consider the use of > the algorithm mentioned in the draft. then It is not valid. There > was not enough time to discuss the whole application layer algorithm > in the 6man (as I had to spend 3 to 5 minutes just explaining it). > If you are still having concerns, please share them here. > > Concerns: The large numbers of sessions and everyone requiring a > separate neighbor discovery multicast address so this blows your > multicast [...] So, the bottom line is it is not scalable. > > Answer: True and not true, This is because it depends on how you set > the maximum number of IIDs. If you set its default value in your > network to something like 5 or 10 or, an in general, a small number, > then this will never happen. I guess this is an issue with network > policy as in my draft I considered setting the default values by use > of the option in the router advertisement which can be set by the > admins of each network. > > Concerns: This lifetime issue should be in another draft and > considered in a separate document. > > Answer: If the others feel this way, then I will do it. The reason > it appears in this document is becauses because I wanted to address > the problem of cutting the connection when the lifetime of an IID > has expired. > > Concerns: Slide 5, we should use large stable storage. > > Answer: It is a wording issue. I guess we already discussed this > offline. Instead of “already assigned” http://tools.ietf. > org/html/rfc4941#section-3.2.1 step 4, we need to clarify it as defined here > http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy-04#section-4 > > @ I could not understand the name :( : In this proposal the > number of addresses in a host increase dramatically. So I feel that > if we are specifying that kind of mechanism, the we should also > specify what happens if the network cannot accommodate them. If you > have so many addresses, in some cases you won’t have connectivity. > There are too many addresses to be able to protect the neighbor > discovery cache. > > Answer: I would improve the document and try to address this as > well. However, I do not presume that this will happen, based on the > responses I received from the other people here. > > -------------------------------------------------- > The term public addresses: > @Keith Moore: > Concerns: All IPv6 addresses are public addresses and should be > available. Not chosen a good term. > > I just obtained that term from from the mailing list. Check this old list : > http://www.ietf.org/mail-archive/web/ipv6/current/msg17792.html > A public address is one intended to be resolvable from higher-layer > IDs such as DNS names. > If this is wrong or I misunderstood the meaning , then I will change > it to “DNS addresses” or another term. > What I knew before: > Global addresses = Router prefix + IID > Local Addresses = local prefix + IID > What I understood: > Public addresses = router prefix + IID and has DNS records (like a domain) > > ------------------------------------------ > Security and Network Policy > @ I could not understand the name :( : Question about this > section of slide “if a user visit a website and harms by a cookie > then we need to change the IID”. Do you think this is security > mechanism to do this? I do not consider to have a policy for the network. > > Answer: I meant http cookies or server side cookies. Because client > side cookies can be harmful if there is a script from a website that > might access the other cookies in your computer. This was just one > reason to change the IID addresses within and outside of the > network. There is nothing mentioned about this directly in the > draft. I probably didn't express this idea correctly so you had a > misconception of what I was trying to say. > > > If there are any more issues that I need to concern please leave > your comment here. > > Thank you, > Best, > Hosnieh > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------