Hi Pekka,
Pekka Savola wrote:
On Wed, 2 Jun 2004, Erik Nordmark wrote:
My concern with using the unspecified address comes from the
experience we had in MAGMA where we had to specify which source
address to use in the MLDv1 packets.
RFC 3590 does allow the unspecified source for MLD messages during DAD, so the parallel for RS works quite fine.
That must be allowed (more or less) for MLD because there is no choice if there are MLD snoopers out there..
Indeed. Let IP devices beware...
Further, some might want to perform some kind of filtering based on the link-local source address, and using the unspecified address makes this impossible.
What type of filtering do you have in mind? What problem would such filtering solve?
I'm mainly thinking of xDSL systems where all the customers appear to be on the same subnet (e.g. a shared IPv4 /19 prefix), but are filtered so that they are actually separate from each other (sorry, I can't describe it much better).
I would also imagine that minimizing the use of the unspecified address might make SEND-like mechanisms easier, because the unspecified address does not belong to just one node, and you cannot distinguish the different nodes using the unspecified address.
I think that the issue with SEND is credible, for router solicitations more than neighbour solicitations (since unspecified address solicitations are for DAD, and the CGA address is in the Target Address.
Given that we were talking about RS here anyway, you may have a point that the unspecified address RS is unidentifiable, except by its signed public key (in the message).
I think that ruling out RS entirely here would be premature though until we consult SEND WG...
It's worth asking the question over there.
Personally, I don't think unidentified and unspecified RS's are given significant power in any case, so there may be no need to identify them (rather, we need to make sure that no additional power goes to them).
If SEND is in use, then certainly there is no CGA, but the message is still signed and sent from an address which is covered by the signature at the end of the packet.
That public key did send the message, and if you know the public key (have seen it before and perhaps trust it), then you could even treat that differently to a device which you've never seen.
[dhcp issues cut].
Greg
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
