> For MIPv6, the *final* goal is to learn if > the client is *authorized* to create bindings, i.e. source > routes, for the _home address_ that it is using. ... > It was an _explicit_ IESG requirement that the authorization > mechanism MUST NOT rely on trusted third parties, i.e. on > a security infrastructure. Hence the "infrastructureless" > methods.
in that case, I think the solution is the null set. because none of: - the fact that traffic from a client appears to come from an address - the fact that the client appears to respond to traffic sent to an address - the fact that a client claims to be authorized to make assertions about an address are suitable as verification that a client is authorized to make assertions about that address. such authorizations are *inherently* made by third parties - i.e. network administrators who are responsible for assigning addresses for use by clients. the *only* way to verify client assertions about address bindings is to verify that the client has been given the authority to make such assertions by the party who is reponsible for doling out those addresses - and the only way to do that (that scales) is to rely on some security infrastructure. such infrastructure doesn't have to involve a "trusted third party" (in the sense of a "third party" that is unrelated to the participating parties and whose only function is to mediate trust) but an infrastructure that involves the parties who have the authority to make assertions about addresses (from IANA down to the site level via the RIRs and ISPs) is inherently necessary to address the problem you claim to be trying to solve. Keith -------------------------------------------------------------------- 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] --------------------------------------------------------------------
