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.
[email protected] 写于 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
> [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
--------------------------------------------------------------------
