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

[Alexandru Petrescu <[e-mail]>]

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)."

> 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
>