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

[Carlos Jesús Bernardos Cano <[e-mail]>]

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

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

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67