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

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 2 Aug 2010 09:35:45 +0100

> Chris, thanks for sharing your opinion.

Actually I mis-read what you wrote, so part of what I wrote I'd
want to modify myself. But the privacy/security point I would
repeat unchanged.

> On RFC 3091 and dupont-ipv6-rfc3041harmful, the recommendations are in
RFC 4901.

Is that the number you meant? That's titled "Protocol Extensions for
Header
Compression over MPLS" Without reading it, that's not the title of an
RFC
that I'd read to discuss the issues of EUI-64 addresses and the issues I
referenced.

> Centrally managed addresses could result in less, with 1 octet at a
minimum.
> This would be a good reason to use the more centralized approach.

Please note that I have never said that centralised addresses are
unsuitable
for anyone. But they are unsuitable for everyone, as issues you don't
discuss
are important (or more) some people's considerations.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 02 Aug 2010 10:51:50 +0200

Le 30/07/2010 13:57, Teco Boot a écrit :
> 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.

I think it wouldn't be good to get around that MUST.

I was thinking about the same thing as you say: if RFC5889 forbids link
local addresses and new Charter wants DHCP then how could both work?

Maybe RFC5889 just discourages the AUTOCONF mechanism from configuring
link-local addresses.  I.e. let DHCP configure global addresses, even
though during the initial DHCP exchanges the link-local addresses are used.

(wondering...)

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

I wouldn't go that far with requiring modified EUI-64 IIDs - why do you
think rfc5889 requires use of modified IIDs?

Let's see first what is the recommendation of RFC5889-to-be with respect
to link-local addresses, and following the WG meeting discussion.

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

I am trying to see where the modified EUI64 ideas come from, I don't see
currently...

Alex

>
> Opinions?
>
> Teco.
>
>
> _______________________________________________ Autoconf mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/autoconf
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 02 Aug 2010 11:00:34 +0200

Le 31/07/2010 13:19, Teco Boot a écrit :
> On using DHCP, the draft charter, workitem 1, specifies usage of
> DHCPv6. When thinking on how this could work, I want to know what
> requirements are.

Right, me too, I think a good question is whether we agree the DHCP
Server sits on a sort of a fixed Gateway to which nodes attach:

     ----------                      ----------
    | Fixed    |                    | Fixed    |
    |DHCPServer|                    |DHCPServer|
     ----------                      ----------
          |                              |
          |                         Fixed Network
          O       Or is it:              |
                                     ----------
     o nodes o                      | Fixed    |
                                    |DHCPRelay |
   o   o       o                     ----------
                                          |
                                          |
                                          O

                                     o nodes o

                                    o   o       o
> Did I catch "un-touched DHCPv6" at the meeting?

I think I did hear that too... I think it could be good idea.

Alex

> On RFC 3091 and dupont-ipv6-rfc3041harmful, the recommendations are
> in RFC 4901.
>
> The change on site duplicates for well generated CGA or private IIDs
> is close to zero. I think duplicate address problems with DHCP
> servers on CPE devices are far larger than self-generated IIDs
> because reboots and non-volatile storage or lazy write.
>
> Using DHCP provided addresses could provide more efficient
> compression with RFC 5444. EUI-64 needs 3 (same OUI in homogenous
> MANET) or 8 octets. CGA or private IIDs needs 8 octets. Centrally
> managed addresses could result in less, with 1 octet at a minimum.
> Op 30 jul 2010, om 15:52 heeft Dearlove, Christopher (UK) het
> volgende geschreven:
>
>> Teco
>>> Question: can we get around a MUST in a standards track RFC? I
>>> don't think so.
>>
>> There is the "don't use that RFC, use another one - or none"
>> approach.
>>
>>> Second question, on first item in charter: do we limit ourself
>>> to MANET routers that has modified EUI-64 link-locals?
>>
>> Definitely not. There are issues with EUI-64. One of these is
>> privacy/security. If I use a device today, and use the same device
>> at a different time and in a different place, it's still clearly
>> identified as the same device. That can be a problem.
>>
>> There's a discussion in RFC 3041. That's obsoleted by RFC 4941. I
>> mention the older version as someone was concered enough to write
>> draft-dupont-ipv6-rfc3041harmful-05.txt that argued against RFC
>> 3041 (but never made it to RFC). My point is, there are issues,
>> and people of goodwill and expertise disagree on the subject.
>> Probably because of different backgrounds and assumptions. One size
>> does not fit all.
>>
>> -- Christopher Dearlove Technology Leader, Communications Group
>> Networks, Security and Information Systems Department BAE Systems
>> Advanced Technology Centre West Hanningfield Road, Great Baddow,
>> Chelmsford, CM2 8HN, UK Tel: +44 1245 242194  Fax: +44 1245 242124
>>
>> BAE Systems (Operations) Limited Registered Office: Warwick House,
>> PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14
>> 6YU, UK Registered in England&  Wales No: 1996687
>>

---

From: Teco Boot <[email-masked]>
Date: Mon, 2 Aug 2010 14:03:41 +0200

> that I'd read to discuss the issues of EUI-64 addresses and the issues I

Sorry, typo. RFC 4941 obsoletes RFC 3041.
RFC 4941 adopted recommendations in dupont-ipv6-rfc3041harmful.

Teco.

---

From: Teco Boot <[email-masked]>
Date: Mon, 2 Aug 2010 14:07:32 +0200

> local addresses and new Charter wants DHCP then how could both work?

The document doesn't say "forbid".

Teco

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 02 Aug 2010 14:29:37 +0200

Le 02/08/2010 14:07, Teco Boot a écrit :
>> I was thinking about the same thing as you say: if RFC5889 forbids
>> link local addresses and new Charter wants DHCP then how could both
>> work?
>

Right, RFC5889-to-be does not say "forbid".

5889-to-be:
> Note that while link-local addresses are assumed to be "on link",
> the utility of link-local addresses is limited as described in
> Section 6.

Ok, DHCPv6 could leave with this, thinking that the utility of 
link-local addresses is only  during the initial DHCP exchanges 
(Solicit-Advertise I believe).

5889-to-be (without WG discussion Maastricht):
>    Note that while an IPv6 link-local address is assigned to each
>    interface as per [RFC4291], in general link-local addresses are of
>    limited utility on links with undetermined connectivity, as
>    connectivity to neighbors may be constantly changing.  The known
>    limitations are:
>
>    o  There is no mechanism to ensure that IPv6 link-local addresses are
>       unique across multiple links, hence they cannot be used to
>       reliably identify routers (it is often desirable to identify a
>       router with an IP address).
>
>    o  Routers cannot forward any packets with link-local source or
>       destination addresses to other links (as per [RFC4291]), while
>       most of the time, routers need to be able to forward packets to/
>       from different links.

Although DHCP Relay sits on a router, DHCP is not "most of the time" in 
that a DHCP Relay will use its global address although the Client sent a 
Solicit using its link-local address - Relay duplicates the packet.

>    Therefore, autoconfiguration solutions should be encouraged to
>    primarily focus on configuring IP addresses that are not IPv6 link-
>    local.

This is fine, because DHCP would configure an IP address on Client which 
is not link-local but global.

Of course this DHCPv6-LL analysis should change when we get the more 
final RFC5889-to-be text.

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 2 Aug 2010 13:45:15 +0100

Essentially RFC 3941 is generating random interface IDs. (There
are practical issues, but really they are about what should be
random working and not e.g. having two nodes use the same PRNG
and repeatedly clash.) It is a solution that is not using EUI-64
(except as a part of a seed for the random process) to ensure
uniqueness. And all I said was that the EUI-64 solution isn't
acceptable in some cases.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Teco Boot
Sent: 02 August 2010 13:04
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Re: [Autoconf] Using DHCPv6 without link-local? Support
onlyEUI-64interfaces?

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

>> On RFC 3091 and dupont-ipv6-rfc3041harmful, the recommendations are
in

Teco.

_______________________________________________
Autoconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/autoconf

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 2 Aug 2010 13:46:37 +0100

I recall Dave Thaler tiptoeing through this minefield in an
autoconf meeting, maybe Stockholm. He seemed to negotiate it.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Teco Boot
Sent: 02 August 2010 13:08
To: Alexandru Petrescu
Cc: [email-masked] [email-masked]
Subject: Re: [Autoconf] Using DHCPv6 without link-local? Support only
EUI-64interfaces?

                    *** WARNING ***

Op 2 aug 2010, om 10:51 heeft Alexandru Petrescu het volgende

> I was thinking about the same thing as you say: if RFC5889 forbids
link

Teco

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 2 Aug 2010 09:39:17 -0700

Hi Teco,

> From: Teco Boot [mailto:[email-masked]]
> Sent: Saturday, July 31, 2010 6:57 AM
> To: Templin, Fred L
> Subject: Re: [Autoconf] Using DHCPv6 without link-local? Support only EUI-64interfaces?
> 
> Fred,
> 
> Do you mean DHCP relay can be used on a node, that request an address
> for itself?

I mean that the client function on a node sends a DHCP
request that is intercepted by a relay function on that
same node. The relay forwards the DHCP request to a DHCP
server, which then sends a reply via the same relay. The
relay then forwards the reply to the client on the same
node, and the client does the appropriate thing.

> 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.
> 2b) If node is provisioned with DHCP server unicast address, it could use that
>     instead of All_DHCP_Servers.
> 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.
> Another drawback of 1: there is a timeout delay when there is no relay or server
> at one hop.

Right, but that's not the scenario I was describing.

> For 2a: the network needs multicast support. Could be SMF.

Ack.

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

That's what VET is essentially saying, yes.

Thanks - Fred
[email-masked]

> Teco
> 
> 
> 
> 
> Op 30 jul 2010, om 17:40 heeft Templin, Fred L het volgende geschreven:
> 
> > Teco,
> >
> >> From: [email-masked] [mailto:[email-masked]] On Behalf Of Teco Boot
> >> Sent: Friday, July 30, 2010 4:58 AM
> >> To: [email-masked] [email-masked]
> >> 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
> > [email-masked]
> >
> >> 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.
> >>
> >>

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 2 Aug 2010 18:55:16 +0200

Teco,

> Do you mean DHCP relay can be used on a node, that request an address

I have tried that a while ago. It works with some limitations (see below).

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

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
encapsulated at every hop, quickly increasing overhead. And I also
don't think that DHCP relaying allows duplicate packet detection.

>    instead of All_DHCP_Servers.

Sure, that is possible if a unicast routing protocol is used.

> Drawback of 1: it can result in high number of relayed DHCP packets, in case

True.

> Another drawback of 1: there is a timeout delay when there is no relay or server

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.

> address to a centrally managed address.

Yes, that seems possible (but I have to re-read the DHCPv6 RFC after
my vacations ;-)

Ulrich

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 2 Aug 2010 10:31:05 -0700

Ulrich,

> From: Ulrich Herberg [mailto:[email-masked]]
> Sent: Monday, August 02, 2010 9:55 AM
> To: Teco Boot
> Cc: Templin, Fred L; [email-masked] [email-masked]
> 15.13 "clients MUST discard any received Relay-forward messages"

The 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. Maybe
you meant section 15.14 "Clients and servers MUST discard any
received Relay-reply messages"? But, it is the node's relay
function (and not the client function) that gets the
Relay-reply so this is not in violation of the spec.

> and

The node's client function (and not the relay function) is the
one that gets the Advertise message when 4-message exchange is
used; the relay function sees only the Relay-reply and then
forwards the Advertise on to the client function. Also, in
2-message exchange there is no Advertise message.

Fred

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 2 Aug 2010 19:44:36 +0200

Fred,

On Mon, Aug 2, 2010 at 7:31 PM, Templin, Fred L
<[email-masked]> wrote:
>[...]

Thanks for that clarification. If this demultiplexing is possible,
than it should indeed not be a problem. Is that explicitly mentioned
in the RFC?

> forwards the Advertise on to the client function.

Same comment as above.

> Also, in

Ulrich

>[..]

---

From: Teco Boot <[email-masked]>
Date: Mon, 2 Aug 2010 19:56:39 +0200

> (ii) section 15.3 "servers and relay agents MUST discard any received

I don't think there is such limitation.
A node that combines client and relay would not send out a packet that does
not conform to the spec.

> encapsulated at every hop, quickly increasing overhead.

Yes, relaying and encap on every hop is a bad idea, I think.
But we don't have a standard track multicast protocol for MANETs.
We also don't have a protocol for service discovery, for learning the
DHCP server address.
This makes our work experimental.

>    And I also

Why not?
SMF hashing should work. Each packet has a random transaction ID.
Or include a SMF-DPD header option.

> But I guess this timeout can be set dynamically?

When 1 is used as a first try, looking for a DHCP-server at one hop, the node 
should wait some time for a response. If no response arrives, it could go to step 2.
The timeout would be a configured parameter, I think.
Maybe it is better to skip such a mechanism. Needs more thoughts.

> Yes, that seems possible (but I have to re-read the DHCPv6 RFC after

Not _during_ your vacation ??  :-))

Teco

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 02 Aug 2010 21:37:55 +0200

Le 02/08/2010 18:55, Ulrich Herberg a écrit :
> Teco,
>
> On Sat, Jul 31, 2010 at 3:56 PM, Teco Boot<[email-masked]>  wrote:
>> Fred,
>>
>> Do you mean DHCP relay can be used on a node, that request an
>> address for itself?
>
>> 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.
>
>  (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)."

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

> 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.
>
>> 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.
>
>> 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.
>
>>>> -----Original Message----- From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of Teco Boot
>>>> Sent: Friday, July 30, 2010 4:58 AM To: [email-masked]
>>>> [email-masked] 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.
>>>>
>>> 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
>>> 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 [email-masked]
>>>
>>>> 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.
>>>>
>>>> to MANET routers that has modified EUI-64 link-locals? I
>>>> think: better think twice.
>>>>
>>>> Opinions?
>>>>
>>>> Teco.
>>>>
>>>>
>>>> _______________________________________________ Autoconf
>>>> mailing list [email-masked]
>> _______________________________________________ Autoconf mailing
>> list [email-masked]

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 2 Aug 2010 23:46:47 +0200

Teco,

On Mon, Aug 2, 2010 at 7:56 PM, Teco Boot <[email-masked]> wrote:
[..]
> A node that combines client and relay would not send out a packet that does

Fred pointed that out. I wonder whether that demultiplexing is clearly
pointed out in the DHCPv6 RFC. But well, too late to change it ;-)
I assume that major DHCPv6 implementations do not implement that
demultiplexing (they'd need to share the UDP port, demultiplex
messsages etc.) (-- I know, that's not so much a problem of the
standardization process.. just wondering here)

> This makes our work experimental.

Indeed. It would make life easier to have such protocols as RFCs
already :-) With SMF, we have at least a protocol which is not so far
from being published as RFC.

> Or include a SMF-DPD header option.

True. But that is defined in SMF, not in DHCPv6 relaying.

> Maybe it is better to skip such a mechanism. Needs more thoughts.

Yes, I also have to think more about it.

> Not _during_ your vacation ??  :-))

hehe, well, my boss would like that ;-)

Ulrich

---

From: Henning Rogge <[email-masked]>
Date: Tue, 3 Aug 2010 07:25:07 +0200

Hello,

is there a reason why we cannot place an DHCPv6-relay on every node for its 
neighbors ? Each node requesting an address/prefix will send out an IP 
datagram with an anycast destination an a linklocal source, which will be 
forwarded by its neighbors (with a unicast) to the DHCPv6-server.

After a node has it's address it switch from DHCP-client to DHCP-relay mode, 
to allow other nodes to connect through this node to the server.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 3 Aug 2010 10:28:59 +0200

Hi Henning,

> forwarded by its neighbors (with a unicast) to the DHCPv6-server.

Sure, that works. DHCP clients would typically send their messages to
the All_DHCP_Relay_Agents_and_Servers multicast address. However, that
necessitates the use of a unicast routing protocol, because the relay
has to have a route towards the DHCP server. The question is, do we
want to depend on that? I think we should also have a running autoconf
mechanism in cases when there is no unicast routing protocol in place.

Ulrich

---

From: "Rogge Henning" <[email-masked]>
Date: Tue, 3 Aug 2010 10:37:08 +0200

> Von: Ulrich Herberg [mailto:[email-masked]] 
> 
> Hi Henning,
> 
> Sure, that works. DHCP clients would typically send their 
> messages to the All_DHCP_Relay_Agents_and_Servers multicast 
> address. However, that necessitates the use of a unicast 
> routing protocol,
I would say we could live with the dependency of a unicast route to the
DHCPv6 server on all addresses which have been sucessfully configured by
this server.

> because the relay has to have a route 
> towards the DHCP server. The question is, do we want to 
> depend on that? I think we should also have a running 
> autoconf mechanism in cases when there is no unicast routing 
> protocol in place.
Are you sure DHCPv6 is a good sollution for this networks ? What kind of
mesh networks use no unicast capable routing protocol ?

Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für 
Kommunikation, Informationsverarbeitung und Ergonomie FKIE 
Kommunikationssysteme (KOM) Neuenahrer Straße 20, 53343 Wachtberg, 
Germany Telefon +49 228 9435-961,   Fax +49 228 9435 685 
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: Teco Boot <[email-masked]>
Date: Wed, 4 Aug 2010 08:10:24 +0200

> standardization process.. just wondering here)

I don't see the problem.

> from being published as RFC.

SMF is experimental.

Teco

---

From: Teco Boot <[email-masked]>
Date: Wed, 4 Aug 2010 08:21:11 +0200

> mechanism in cases when there is no unicast routing protocol in place.

This is the 2b scenario.
A problem is that all neighbors relay the DHCP request. In a dense network,
(to) many neighbors will relay. One can think of a backpressure mechanism. 
Another problem is the discovery of the DHCP server(s). Easy to solve,
solutions are around (BRDP is just one of them). But in many solutions,
the MANET protocol is adjusted for service discovery support. (BRDP is not
a MANET protocol, it is an RA extension).
I don't think the need for a routing protocol for forwarding packages is a
problem. There are no functional MANETs without. 

Teco.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 4 Aug 2010 08:29:34 +0200

On Wed August 4 2010 08:21:11 Teco Boot wrote:
> >> is there a reason why we cannot place an DHCPv6-relay on every node for
> >> its neighbors ? Each node requesting an address/prefix will send out an
> >> IP datagram with an anycast destination an a linklocal source, which
> >> will be forwarded by its neighbors (with a unicast) to the
> >> DHCPv6-server.
> > 

> a MANET protocol, it is an RA extension).
Does a DHCP-reply from a relay contain the address of the DHCP-server ?

> problem. There are no functional MANETs without.
I agree with this.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Wed, 4 Aug 2010 09:39:38 +0200

> Does a DHCP-reply from a relay contain the address of the DHCP-server ?

We have RFCs that document our protocols.
Is RFC3315 unclear on this?

Relay simply relays the DHCP-reply from server to client (or to downstream relay),
after stripped the Relay Message option.
When no relay adds a Relay Agent Option, server may send Server Unicast Option.
Clients may ask for the Server Unicast Option.

Teco

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 04 Aug 2010 15:27:37 +0200

Hi Alex,

> 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

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Aug 2010 16:23:36 +0200

> 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

---

From: Joe Macker <[email-masked]>
Date: Thu, 5 Aug 2010 14:21:57 -0400

We hacked something like this many years ago in working manet stub networks and it worked but had some performance limitations. 
I presented a slide somewhere in manet many years ago and the basic description was in a few reports and a book chapter.

The unicast autoconf builds out naturally at the connected edges for the stub area case which was the nice feature.