Re: [Autoconf] Using DHCPv6 without link-local? Support only EUI-64interfaces?

[Alexandru Petrescu <[e-mail]>]

Le 04/08/2010 15:27, Carlos Jesús Bernardos Cano a écrit :
> Hi Alex,
>
> On Mon, 2010-08-02 at 21:37 +0200, Alexandru Petrescu wrote:
>> Le 02/08/2010 18:55, Ulrich Herberg a écrit :
>>> Teco,
>>>
>>> On Sat, Jul 31, 2010 at 3:56 PM, Teco Boot<[e-mail]>   wrote:
>>>> Fred,
>>>>
>>>> Do you mean DHCP relay can be used on a node, that request an
>>>> address for itself?
>>>
>>> I have tried that a while ago. It works with some limitations (see
>>> below).
>>>
>>>>
>>>> I think it could work this way: 1) Node queries with link-local to
>>>> All_DHCP_Relay_Agents_and_Servers. 2a) Node acts as also relay and
>>>> queries with ULA (site-local) to All_DHCP_Servers.
>>>
>>> Do you mean that a node is DHCP client and relay in the same time?
>>> That is not possible according to RFC3315, which says (i) in section
>>>   15.13 "clients MUST discard any received Relay-forward messages" and
>>>   (ii) section 15.3 "servers and relay agents MUST discard any
>>> received Advertise messages".
>>
>> Ah!  This is seem to contradict something in MEXT context where
>> draft-ietf-mext-nemo-pd-05 proposes "This relay agent function is
>> co-located in the MR with the DHCPv6 client function (see Figure 2)."
>
> I don't think it contradicts it. As Fred mentioned in his e-mail:
> "client function would never see a Relay-forward, because that is
> generated by the relay function and sent to either the unicast address
> of a server or All-DHCP-Servers multicast."

I guess that can be understood so, provided there being two DHCP 
processes: one Relay and one Client.

Alex

>
> Thanks,
>
> Carlos
>
>>
>>> Also, the relay would need to have a direct unicast connection to the
>>> central node or use other relaying mechanisms such as SMF (as you
>>> mentioned below), because multiple relaying is not really feasible in
>>> DHCPv6 itself: Relaying uses encapsulation, so packets would be
>>                      ^^^^^^^^^^^^^^^^
>> Clarification: yes, relaying implies encapsulation when Relay relays to
>> another Relay, but when Relay to Server - it's non-encapsualted.
>>
>>> encapsulated at every hop, quickly increasing overhead. And I also
>>> don't think that DHCP relaying allows duplicate packet detection.
>>
>> Duplicate packet detection?  What is it for?
>>
>> Alex
>>
>>>> 2b) If node is provisioned with DHCP server unicast address, it
>>>> could use that instead of All_DHCP_Servers.
>>>
>>> Sure, that is possible if a unicast routing protocol is used.
>>>
>>>> I think this is in line with your RFC 5558.
>>>>
>>>> Drawback of 1: it can result in high number of relayed DHCP
>>>> packets, in case of many neighbors.
>>>
>>> True.
>>>
>>>> Another drawback of 1: there is a timeout delay when there is no
>>>> relay or server at one hop.
>>>
>>> But I guess this timeout can be set dynamically?
>>>
>>>>
>>>> For 2a: the network needs multicast support. Could be SMF.
>>>
>>> Yes, that could be a possibility.
>>>
>>>
>>>>
>>>> For both 2a and 2b: a temporally used unicast address must be
>>>> routable. So this DHCP mechanism can only be used as a second
>>>> step, moving from the self-generated address to a centrally
>>>> managed address.
>>>
>>> Yes, that seems possible (but I have to re-read the DHCPv6 RFC after
>>>   my vacations ;-)
>>>
>>> Ulrich
>>>
>>>>
>>>> Teco
>>>>
>>>>
>>>>
>>>>
>>>> Op 30 jul 2010, om 17:40 heeft Templin, Fred L het volgende
>>>> geschreven:
>>>>
>>>>> Teco,
>>>>>
>>>>>> -----Original Message----- From: [e-mail]
>>>>>> [mailto:[e-mail]] On Behalf Of Teco Boot
>>>>>> Sent: Friday, July 30, 2010 4:58 AM To: [e-mail]
>>>>>> [e-mail] Subject: [Autoconf] Using DHCPv6 without
>>>>>> link-local? Support only EUI-64interfaces?
>>>>>>
>>>>>> RFC3315: ...     The client MUST use a link-local address
>>>>>> assigned to the interface for which it is requesting
>>>>>> configuration information as the source address in the header
>>>>>> of the IP datagram.
>>>>>>
>>>>>> Question: can we get around a MUST in a standards track RFC? I
>>>>>> don't think so.
>>>>>
>>>>> If the MANET router only behaves as a client on an internal link
>>>>> (e.g., a loopback) but behaves as a relay on its MANET
>>>>> interfaces, then link-locals need not be exposed for DHCPv6
>>>>> purposes. There are other reasons why link-locals might need to
>>>>> be considered for MANETs, but I'm not sure this is one of them.
>>>>>
>>>>> Fred [e-mail]
>>>>>
>>>>>> The to be posted proposed text for to be RFC5889 would say
>>>>>> that if link-locals are used, there are potential problems
>>>>>> when using other than modified EUI-64 IIDs, and therefore must
>>>>>> be based on modified EUI-64 IIDs.
>>>>>>
>>>>>> Second question, on first item in charter: do we limit ourself
>>>>>> to MANET routers that has modified EUI-64 link-locals? I
>>>>>> think: better think twice.
>>>>>>
>>>>>> Opinions?
>>>>>>
>>>>>> Teco.
>>>>>>
>>>>>>
>>>>>> _______________________________________________ Autoconf
>>>>>> mailing list [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/autoconf
>>>>
>>>> _______________________________________________ Autoconf mailing
>>>> list [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/autoconf
>>>>
>>> _______________________________________________ Autoconf mailing list
>>> [e-mail] https://www.ietf.org/mailman/listinfo/autoconf
>>>
>>
>> _______________________________________________
>> Autoconf mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/autoconf
>