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 --------------------------------------------------------------------
