Fred,
Thanx for the correction.
Do you see any aspect of CGA use with DHCP that is not currently covered by
RFC 3315?
jak
----- Original Message -----
From: "Templin, Fred L" <[EMAIL PROTECTED]>
To: "James Kempf" <[EMAIL PROTECTED]>; "marcelo bagnulo braun"
<[EMAIL PROTECTED]>; "Stig Venaas" <[EMAIL PROTECTED]>
Cc: "INT Area" <[EMAIL PROTECTED]>
Sent: Tuesday, June 19, 2007 2:07 PM
Subject: RE: DHCPv6 and CGA (was: Re: [Int-area] SeND & CGA Extensions BOF)
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
