Hi, Brian and all, We are doing an open source implementation of SeND/CGA and some extension what CSI WG is doing together with Beijing University of Post and Communication. So far, the SeND/CGA implementation has been done and proved work well through a little bit update may need. We will publish our source code for download later this month or early next month after we finish the extension implementation. Before us, Docomo also did experimental implementation back to 2006.
Best regards, Sheng > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Brian > E Carpenter > Sent: Thursday, July 23, 2009 12:32 PM > To: [email protected] > Cc: [email protected]; [email protected]; [email protected]; > [email protected] > Subject: Re: Node Requirements: Issue 13 - CGA/SeND support > > What information do we have from the real world about deployability? > > It would be foolish to mandate something that doesn't work well. > > Brian > > On 2009-07-23 16:03, [email protected] wrote: > > Hesham, > > > > I agree with you, the Node cannot know this, it can only do the right thing > once the SeND process starts. Do people feel that SeND should be a basic feature > of IPv6 that all nodes SHOULD support? > > > > John > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of ext > Hesham Soliman > > Sent: Wednesday, July 22, 2009 11:46 PM > > To: Laganier, Julien; Thomas Narten; [email protected] > > Subject: Re: Node Requirements: Issue 13 - CGA/SeND support > > > > Looks good in general, but I'm not sure if the host can always determine the > nature of the link or the level of security available on that link. It can > probably infer (sometimes inaccurately) but it's not laways possible to know. > > > > I agree with the SHOULDs and the intention of the MAY, I just don't know if > a host knows enough to decide about the MAY. > > > > Hesham > > > > > > On 23/07/09 12:59 PM, "Laganier, Julien" <[email protected]> wrote: > > > >> Just for the sake of getting the discussion started, I drafted some > >> text we can discuss: > >> > >> Secure Neighbor Discovery [RFC3971] SHOULD be supported. [RFC4861] > states: > >> > >> Cryptographic security mechanisms for Neighbor Discovery are outside > >> the scope of this document and are defined in [RFC3971]. > >> > >> Secure Neighbor Discovery [RFC3971] SHOULD be used when physical > security > >> on the link is not assured. [RFC3971] states: > >> > >> The SEND protocol is designed to counter the threats to NDP. These > >> threats are described in detail in [22]. SEND is applicable in > >> environments where physical security on the link is not assured (such > >> as over wireless) and attacks on NDP are a concern. > >> > >> Secure Neighbor Discovery [RFC3971] MAY be disabled when the link is > >> point-to-point and link-layer security is assured, including mutual > >> authentication of the link end-points and data origin integrity > protection. > >> > >> What do you think? > >> > >> --julien > >> > >> > >>> -----Original Message----- > >>> From: [email protected] [mailto:[email protected]] On Behalf > >>> Of Thomas Narten > >>> Sent: Tuesday, July 21, 2009 2:36 PM > >>> To: [email protected] > >>> Subject: Node Requirements: Issue 13 - CGA/SeND support > >>> > >>> Tim Chown <[email protected]> writes: > >>> > >>>> What about CGA/SeND support? I can't see any reference to this > >>>> currently. Should there be? It's often waved as the answer to > >>>> make rogue RAs 'go away', so perhaps we should. > >>> I agree we need to have a section that addresses this topic. > >>> > >>> If no one suggests text, I'll take a stab. > >>> > >>> Thomas > >>> -------------------------------------------------------------------- > >>> 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 > >> -------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > > 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 > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------
