Erik, > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Erik > Nordmark > Sent: Wednesday, December 02, 2009 11:31 PM > To: Hemant Singh (shemant) > Cc: ipv6@ietf.org; Pekka Savola > Subject: Re: speaking of ND Proxy and NBMA etc. > > Hemant Singh (shemant) wrote: > > > 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. > > I definitely had other concerns around RFC 4389 around the weaknesses in > loop avoidance. ND proxy in essence forwards IP (ND) packets without > decrementing ttl, which can lead to catastophic loops. The RFC tries to > ameliorate that by detecting loops. However, the loop detection is based > on receiving RAs (with the P-bit) which handles some cases. But it isn't > robust against somebody connecting what was two Ethernet segments after > ND proxy has sent its two P-bit RAs. > > Thus I personally don't think this approach is fit as a standards track > document. > > > 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. > > draft-ietc-csi-proxy-send is underway but is a bit subtle in its > applicability. The idea around RFC 4389 is that the proxy isn't known to > the other nodes. Yet proxy-send is based on explicitly assigning a > ceritificate and associated trust to the proxy node. See text around > The Secure Proxy ND becomes part of the trusted infrastructure just > like a SEND router. The Secure Proxy ND is granted a certificate > that specifies the range of addresses for which it is allowed to > perform proxying of SEND messages > > Such an approach is workable for the Mobile IP scenario, because there > the MN and HA have a relationship thus it is reasonable for the MN to > trust the HA. > > But it doesn't seem to fit the transparent case of RFC 4389. > > If there are networks "that need ND proxy" as you say, and at the same > time have the threats that SeND was designed to handle (the threats are > listed in RFC 3756), then I think there is an architectural disconnect. > To be able to secure the network some constraints need to be placed on > who can advertise things in Neighbor Discovery messages and that seems > to be fundamentally at odds with any transparent ND proxying. > > I suspect such cases are best handled (when SeND can't be deployed on > the link) by splitting what is one link into separate links (by using > existing techniques like VLANs, or perhaps inventing some new technique > above layer 2) so that the security threats related the shared link goes > away. > > I think that this is in essence what is done for IPv4 since the DHCPv4 > address assignment essentially is used to establish point-to-point > connectivity between the router and each peer; there is no shared > multicast or broadcast traffic needed on the link to set this up. > IPv6 is different in its reliance on not only link-local addresses but > also on multicast RS and RA packets to do the initial setup.
Some links rely on unicast RS/RA and not multicast. Wouldn't unicast-only proxy ND avoid the looping issues you were concerned with? Fred fred.l.temp...@boeing.com > Regards, > > Erik > > > 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. > > > > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------
