If people think ND-Proxy is of enough commercial/deployment interest, and
people feel that security is a major issue, then either the IPv6 WG could
take up the task of extending SEND for proxy ND or SEND could recharter/have
a BOF for that purpose.
The key here is "commercial/deployment interest". IMHO,
starting/rechartering a WG or adding an item to the IPv6 WG charter just
because its a technically interesting problem isn't sufficiently compelling
for devoting IETF resources to the task.
My 0.02 won.
jak
----- Original Message -----
From: "Fred Templin" <[EMAIL PROTECTED]>
To: "James Kempf" <[EMAIL PROTECTED]>; "Erik Nordmark"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, March 02, 2004 5:44 PM
Subject: Re: ndproxy and SEND
> If what you are both saying is correct, then perhaps either SEND
> or ND-Proxy (or both) is only half-baked. Which one is it?
>
> Fred L. Templin
> [EMAIL PROTECTED]
>
> James Kempf <[EMAIL PROTECTED]> wrote:
> Hi Erik,
>
> > The fact that SEND doesn't currently provide security for proxy neighbor
> > advertisements is an indication that 1) there isn't much perceived need
> > for it and/or 2) it is hard to do since authorization is a challenge.
> >
>
> Indeed, proxy ND was perceived to be one of two hard problems during the
> SEND design discussions, the other being cert-based ND, which would
require
> provisioning of every host with a cert. After discussion, the SEND WG
> decided not to move forward with a solution primarily for tactical
reasons.
> In short, the WG felt that it would be better to wait for clear indication
> of market acceptance for SEND rather than continuing and doing yet another
> RFC that nobody really cared enough about to implement, put in their
> products, and deploy. The original idea was to wait for some time to see
> whether market acceptance was forthcoming, then do a BOF and restart the
WG
> to work on the remaining problems. It's an interesting technical problem,
> though. From one perspective, one could view it as an instance of trust
> transitivity, which is something that in general is not considered to be
> very secure, hence the authorization challenge.
>
> jak
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [EMAIL PROTECTED]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
