Julien, Thanks - we will update our draft to change the info that now the CSI group is working on SEND extensions for ND Proxy and it's Work in Progress. However, one original intent of our draft is still valid that some deployments want to use ND Proxy but will not use SEND.
Hemant -----Original Message----- From: Laganier, Julien [mailto:juli...@qualcomm.com] Sent: Tuesday, November 17, 2009 9:31 PM To: Hemant Singh (shemant); Pekka Savola Cc: ipv6@ietf.org; draft-ietf-csi-proxy-s...@tools.ietf.org; csi-cha...@tools.ietf.org Subject: RE: speaking of ND Proxy and NBMA etc. Hemant, The CSI WG has been chartered in 2008 to develop an ND proxy support for SEND and has a corresponding work item: <http://tools.ietf.org/html/draft-ietf-csi-proxy-send-01> --julien > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > Hemant Singh (shemant) > Sent: Thursday, November 12, 2009 2:13 AM > To: Pekka Savola > Cc: ipv6@ietf.org > Subject: RE: speaking of ND Proxy and NBMA etc. > > Yes. Cable access concentrators (also called a CMTS (Cable Modem > Termination System)) for ipv4 support an ARP Proxy. So it was natural > when the CMTS moved to also supporting IPv6, having the CMTS support ND > Proxy was a natural transition. Two different CMTS vendors (one is > Cisco) support ND Proxy as of 2007. Cable deployment is a NBMA network > where client behind our cable modem cannot communicate directly to each > other. So the CMTS ND Proxy catches DAD duplicates and sends an NA and > the CMTS also responds to address resolution NS's with an NA. That is > the extent of the ND Proxy on cable access concentrators. Cable data > standards in Docsis 3.0 have also recommended ND Proxy. Note also that > 6lowpan has also recommended ND Proxy in their draft - > http://www.ietf.org/id/draft-ietf-6lowpan-nd-07.txt. The v6ops IPv6 CE > Home Router has recommended ND Proxy for the router. A v6ops document > cannot reference an Experimental RFC - this was the first motive behind > moving the ND Proxy RFC to be a Standards Track document. > > I personally think RFC 4389 is well shaken out for a doc - as we say in > our new short note, the only reason they didn't make the ND Proxy doc a > Standards Track doc because ND Proxy did not support SEND extensions. > The SEND extensions was work TBD with another IETF WG but that group is, > I think, 4 years and counting for not taking this work. But there are > networks that need ND Proxy without use of SEND. > > Hemant > > -----Original Message----- > From: Pekka Savola [mailto:pek...@netcore.fi] > Sent: Thursday, November 12, 2009 3:51 PM > To: Hemant Singh (shemant) > Cc: ipv6@ietf.org > Subject: Re: speaking of ND Proxy and NBMA etc. > > On Wed, 11 Nov 2009, Hemant Singh (shemant) wrote: > > http://www.ietf.org/id/draft-wbeebee-6man-nd-proxy-std-00.txt > > Do we already have implementations? What are the implementation > experiences? Were all the features of the spec useful, or should > something be changed (added, removed, clarified)? > > This is not procedurally required for PS, but if there are a lot of > implementations already, this would be a strong argument for going to > PS. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
