> I think it is already possible for a node to use CGAs with > DHCPv6.
This was what I meant in "NETLMM using DHCP" where it says: "IPv6 RAs can carry prefix options whereas IPv4 RAs only carry the addresses of routers. IPv6 MNs can auto-configure addresses from advertised prefixes and propose them to the MAP's DHCPv6 server instead of allowing the DHCPv6 server to select addresses." (see: http://tools.ietf.org/html/draft-templin-autoconf-netlmm-dhcp-04). > The node > sends an Interface ID Option (Section 22.18 of RFC 3315) > along with the > REQUEST, containing a cryptographically generated interface > id. The DHCP server assigns the address having this id. AFAICT, according to ([RFC3315], Section 22.18)) that is not what the Interface ID option is used for, and would not work as you have described it. > For this to work, the subnet > prefixes must be advertised in the RA even though the 'M' > flag is set, since > the cryptographic generation process uses the subnet prefix. > If the RA > advertises more than one subnet, there might be a problem, > since there is no > way to indicate to the server which subnet the host has selected. Not true; the client can configure a CGA address from an advertised prefix and "propose" it to the server by including it in an IA Address option ([RFC3315], Section 22.6). The server should then be willing to assign the address to the client as long as it isn't a duplicate. Fred [EMAIL PROTECTED] > Most of the reasons mentioned in this thread as to why this > might be useful > strike me as somewhat speculative, if still within the realm > of possibly > useful. The only reason that I can see as being soundly > justified is that > the NS/NA IP address to link address resolution process for a > DHCP assigned > address is subject to address spoofing unless the address is a CGA. > > I think this topic (how to use CGAs with DHCP) rates about a > 4-9 page RFC > that essentially expands on the above, indicating what hosts, > routers, and > DHCP servers must do in order to make it possible. > > Sorry it took so long to get back on this, I was travelling without > reasonable email access. > > jak > > > ----- Original Message ----- > From: "marcelo bagnulo braun" <[EMAIL PROTECTED]> > To: "Stig Venaas" <[EMAIL PROTECTED]> > Cc: "INT Area" <[EMAIL PROTECTED]> > Sent: Monday, June 04, 2007 8:13 AM > Subject: Re: [Int-area] SeND & CGA Extensions BOF > > > Hi Stig, > > thanks for the comments, see reply in line... > > El 04/06/2007, a las 12:51, Stig Venaas escribió: > > > > I agree that there are some challenges, but we should work on > > understanding what those are, and see if it is worthwhile to work > > on it. > > well the proposed work is to understand those rather than build > solutions. > > the main question at this stage is what are the motivations for a node > that needs to use CGAs to use also dhcp > > If we determine that there are relevant scenarios where a > host needs to > use CGA and dhcp simoultaneously, then we should explore how to make > these two work togehter, which is the proposed work. > > So as i understand it, if we see use cases for using cga and dhcp in > the same node, then we have a motivation for this work item (in this > bof or somewhere else, but this means that this is interesting work) > > > I for one would like to think more about that (I guess you > > may have thought more about this than me Markus :) > > > > I have only passing knowledge of CGAs, but I wonder if > there could also > > be ways of proving that an address really was handed out by a given > > DHCP server. > > i guess you could envision different ways of doing that, ranging from > modifier ranges of multikey cgas or other approaches, it > really depends > on what are the motiviatiosn for doing so, do you think there may be a > case for needing that? > > thanks, marcelo > > > > > > Stig > > > >> > >>> > >>> I don't see a single good reason for standardizing that > but multiple > >>> reasons why not to. If someone really cares, I can provide the > >>> reasons > >>> off-band :) > >>> > >> > >> please expand on this since seems to be a central point for this > >> proposed item > >> > >> Thanks again, marcelo > >> > >>> Cheers, > >>> > >>> -Markus > >>> > >>> > >> > >> > >> > >> _______________________________________________ > >> Int-area mailing list > >> [email protected] > >> https://www1.ietf.org/mailman/listinfo/int-area > > > > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/int-area > > > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/int-area > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
