Subject: Re: Francis's INput at the Design Meeting

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 19 Sep 2000 01:42:27 +0900

sorry, this is a resend (due to From: filter)

------- Forwarded Message

To: [email-masked]
cc: [email-masked]
In-reply-to: bound's message of Mon, 18 Sep 2000 12:01:47 -0400.
      <[email-masked]> 
X-Template-Reply-To: [email-masked]
X-Template-Return-Receipt-To: [email-masked]
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD  90 5F B4 60 79 54 16 E2
Subject: Re: Francis's INput at the Design Meeting 
From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 19 Sep 2000 01:15:59 +0900
Sender: itojun@localhost

>>> How many dhcpv4 implementors have looked at the ND daemon to do
>>> stateless addrconf and the code?  We want to reuse much from that as
>>> IPv6 implementors as possbile.
>>What's an ND Daemon?
>Neighbor Discovery Daemon.  Processes Ipv6 stateless parts and will know
>if dhcpv6 should be started.

	the above discussion/comment looks very implementation dependent for me.
	(maybe I don't have enough context with me - sorry if this is the case)

	there are people implementing ND in the kernel (for example
	KAME/NRL, just like BSD did for IPv4 ARP), and there are people
	implementing ND in the userand (for example INRIA, grab ND messages
	via ICMPv6 socket).  I have not seen other implementation in detail
	enough, but my feeling is that kernel ND implementation is more common
	at this moment.

	independent from where ND is implemented, we need to have some
	interaction between ND code and DHCPv6 code, in terms of "M" bit
	on RA message.  here are couple of examples:
	- (kernel ND implementation) inform of the existence of "M" bit
	  via some signal or whatever
	- (kernel ND implementation) DHCPv6 client code watches RA message
	  by itself, by listening to an ICMPv6 socket
	- (userland ND implementation) implement DHCPv6 client and stateless
	  autoconf into a single daemon.
	- (userland ND implementation) define inter process communication
	  between DHCPv6 client daemon and stateless autoconf daemon

itojun

------- End of Forwarded Message

---

From: Jim Bound <[email-masked]>
Date: Mon, 18 Sep 2000 14:47:20 -0400

>	(maybe I don't have enough context with me - sorry if this is the case)

It was just for discussion.  Yes it can be in the kernel or user space.

Correct.  What we don't want to do is make this interaction difficult
with the spec.

regards,
/jim